Concurrency Control

Essence

Concurrency Control is the archetype for making simultaneous action safe. It applies when several actors, processes, teams, or workflows can touch the same resource, record, decision, space, or state at the same time. The aim is not to eliminate parallelism. The aim is to let harmless parallel work proceed while protecting the places where timing, order, ownership, or capacity can change the outcome.

The core move is to replace accidental interleaving with explicit coordination. Sometimes that means one actor at a time. Sometimes it means partitioning the work so actors no longer collide. Sometimes it means letting everyone proceed and validating before commit. In social settings it can mean facilitation, visible ownership, appeal paths, or turn-taking. Across domains, the structure is the same: simultaneous work needs rules around shared surfaces.

Compression statement

When multiple actors or processes operate at the same time on shared resources, state, decisions, or attention, define access, isolation, ordering, conflict detection, and resolution rules so concurrency produces throughput rather than corruption, duplicate work, or deadlock.

Canonical formula: simultaneous work + shared mutable surface + timing-sensitive conflict risk + explicit coordination rule => safe parallel progress

When to Use This Archetype

Use this archetype when parallel activity creates value but also creates interference risk. The clearest sign is a shared mutable surface: a database row, a budget, an inventory item, a patient chart, a machine, a shared document, a meeting agenda, a customer account, or a decision authority. If two actors can read, write, reserve, approve, promise, or occupy the same thing in ways that affect one another, concurrency control is relevant.

It is especially useful when errors depend on timing. If the outcome changes because one actor happened to arrive first, save later, reserve faster, or hold a resource while waiting for another, the system needs a deliberate rule. That rule might be a lock, a reservation, a version check, an owner boundary, a queue, a merge review, or a human facilitation protocol. The mechanism varies; the archetype is the governing pattern.

Do not use this archetype merely because work is busy or because many tasks are queued. If the problem is too much active work, consider Work-in-Progress Limiting. If the problem is request arrival rate, consider Rate Limiting. If the problem is waiting order, consider Queue Discipline Design. Concurrency Control is specifically about simultaneous interference over shared resources or shared state.

Structural Problem

The structural problem is that useful overlap can become unsafe overlap. Multiple actors may each behave reasonably from their local perspective while collectively producing a wrong state. One team updates a record while another acts on the old version. Two services sell the same inventory. Two maintainers lock different resources and then wait forever for the other resource. Two writers overwrite each other’s edits. A committee tries to amend, vote, and debate at the same time, leaving no one sure what decision was actually made.

The shared surface may be obvious, such as a database record or a physical machine. It may also be hidden, such as customer trust, approval authority, budget availability, downstream capacity, or the meaning of a shared artifact. Hidden shared state is why concurrency failures often surprise people: the actors thought they were working independently, but their actions met downstream.

The underlying tension is speed versus integrity. Parallelism improves responsiveness and throughput, but the contested part of the system needs a rule strong enough to preserve correctness, safety, fairness, and accountability.

Intervention Logic

The intervention begins by mapping concurrency. Identify who or what can act at the same time, then identify the shared surfaces those actions affect. Next, classify the conflict. A read/write conflict needs different controls from overbooking, duplicate outreach, inconsistent approval, priority dispute, or deadlock.

After classification, choose the weakest sufficient control. If conflict can be designed away, partition the work or assign ownership boundaries. If the contested section is small but high-risk, serialize that critical section. If conflicts are rare and recoverable, allow optimistic parallel work and validate before commit. If people are affected, add transparent priority rules and appeal paths. If mutual waiting is possible, add ordering rules, timeouts, or deadlock detection.

A good concurrency-control design protects the shared surface without freezing the whole system. It should keep independent work parallel, make contested work safe, and preserve a visible record of conflicts and resolutions.

Key Components

Concurrency Control governs simultaneous action over shared surfaces, so its components first make the overlap visible and then choose the weakest sufficient rule for each kind of conflict. The Concurrent Actor Map names the actors, processes, services, or workflows that can act at the same time, while the Shared Resource Map identifies what they can touch — records, budgets, equipment, customers, decision rights, and attention channels — including hidden shared state like downstream capacity or shared trust. The Conflict Mode Classification distinguishes lost updates, double bookings, duplicate claims, priority disputes, inconsistent approvals, and deadlocks, preventing the design from using one favorite mechanism for every kind of interference. The Coordination Rule is the chosen response — partition, serialize, reserve, isolate, validate, merge, or escalate — and it must be explicit enough that actors can apply it and auditors can reconstruct it.

The remaining components shape how the coordination rule actually behaves at the contested points. The Isolation Level sets how protected one actor's in-progress work is from another's, trading interference against waiting. The Critical Section Boundary draws the line narrowly around what truly must be protected so the rest of the work stays parallel. The Ordering or Admission Rule turns accidental timing into a deliberate rule based on priority, fairness, role, or sequence whenever multiple actors want the same surface. The Conflict Detection Rule specifies how the system recognizes that two actions collided — through version tokens, timestamps, audit records, or human review — and the Conflict Resolution Rule defines the recovery path of retry, merge, reject, rollback, compensate, escalate, or serialize, preserving accountability rather than silently overwriting one actor's work. A Progress and Fairness Guard protects against the failures the controls themselves can create — starvation, livelock, indefinite waiting, illegitimate priority capture — and the Concurrency Monitoring Signal tracks waits, retries, conflicts, hot spots, and bypasses so the system can tell whether it is under-controlled or over-serialized.

Component	Description
Concurrent Actor Map ↗	This component names the actors, processes, services, teams, or workflows that can act at the same time. Without it, designers may solve the wrong problem: a sequential workflow does not need concurrency control, while an apparently sequential workflow may hide simultaneous side effects.
Shared Resource Map ↗	The shared resource map identifies what can be touched by more than one actor. It includes records, budgets, equipment, rooms, customers, artifacts, decision rights, and attention channels. This is the anchor component of the archetype because concurrency matters only where simultaneity meets something shared.
Conflict Mode Classification ↗	Not all concurrency conflicts are alike. A lost update, double booking, duplicate claim, priority dispute, inconsistent approval, and deadlock each require different treatment. Classification prevents a design from using one favorite mechanism, such as locking, for every kind of interference.
Coordination Rule ↗	The coordination rule says how simultaneous actors are allowed to interact with the shared surface. It may partition, serialize, reserve, isolate, validate, merge, or escalate. The rule should be explicit enough that actors can apply it and auditors can reconstruct it.
Isolation Level ↗	Isolation level sets how protected one actor’s in-progress work is from another actor’s work. Strong isolation lowers interference but may increase waiting. Weak isolation allows more overlap but may require validation and conflict repair.
Critical Section Boundary ↗	The critical section is the part of work where simultaneous access is unsafe. Drawing this boundary narrowly is important: it protects what must be protected while leaving the rest of the work parallel.
Ordering or Admission Rule ↗	When multiple actors want a contested surface, the system needs a deliberate way to decide who enters, commits, reserves, speaks, or acts next. This turns accidental timing into a rule based on priority, fairness, safety, role, or sequence.
Conflict Detection Rule ↗	Some designs prevent conflict upfront; others detect conflict later. A conflict detection rule specifies how the system knows that two actions collided. It may use version tokens, timestamps, audit records, alerts, or human review.
Conflict Resolution Rule ↗	When a conflict appears, the system needs a recovery path. Resolution may mean retrying, merging, rejecting, rolling back, compensating, escalating, or serializing. A good rule preserves accountability instead of silently overwriting one actor’s work.
Progress and Fairness Guard ↗	Concurrency controls can create new failures: starvation, indefinite waiting, livelock, or illegitimate priority capture. A progress and fairness guard ensures that the design remains live and legitimate.
Concurrency Monitoring Signal ↗	Monitoring tracks waits, retries, conflicts, deadlocks, stale writes, hot spots, and bypasses. These signals make the control tunable. Without them, the system cannot know whether it is under-controlled or over-serialized.

Common Mechanisms

A mutex or lock implements exclusion: one actor enters a critical section while others wait. This is useful when simultaneous access is unsafe, but it can become a bottleneck if applied too broadly.

Transaction isolation groups operations so that intermediate states are protected. It is common in databases, but the same logic appears whenever a set of changes should be treated as a protected unit.

An optimistic concurrency check lets actors work in parallel and validates before commit. It works best when conflicts are uncommon and retry or merge is acceptable. It fails when partial action is irreversible.

A semaphore or permit system limits how many actors can access a constrained class of resources. This is often closer to concurrency limiting, but it can support concurrency control when the risk is over-claiming capacity.

A reservation calendar serializes access to rooms, machines, people, or attention windows. It turns simultaneous claims into scheduled claims.

A collaborative editing protocol uses ownership sections, comments, branches, version tokens, or merge prompts to prevent silent overwrite. This mechanism makes the archetype visible in human knowledge work.

Facilitated turn-taking controls simultaneous speech, amendments, or decisions in meetings and governance settings. It is concurrency control for shared attention and shared procedural state.

A merge conflict review reconciles incompatible parallel changes before acceptance. It is not the archetype itself; it is a mechanism for one branch of the archetype.

Deadlock timeout and detection identifies or breaks mutual waiting. It is a guardrail for one failure mode, not the whole pattern.

An ownership assignment matrix makes responsibility boundaries visible so parallel actors know which surfaces they may modify and where they must coordinate.

Parameter / Tuning Dimensions

The first tuning dimension is control strength. Stronger controls, such as strict locks or serial review, reduce corruption risk but increase waiting. Weaker controls, such as optimistic validation, preserve speed but require detection and recovery.

The second is granularity. A coarse lock or broad ownership area is easy to understand but may block safe work. A fine-grained rule preserves parallelism but increases complexity and maintenance burden.

The third is conflict policy. Some systems prevent conflicts before action; others detect them at commit time; others allow conflicts and reconcile later. The right choice depends on reversibility, safety, conflict frequency, and social legitimacy.

The fourth is priority logic. Access may be first-come, role-based, risk-based, capacity-based, seniority-based, randomized, or adjudicated. In human systems, this tuning dimension is ethically important because it shapes opportunity and trust.

The fifth is retry and escalation behavior. A system can retry automatically, ask the actor to merge, escalate to an owner, or abort. Unbounded retries can create livelock, while over-escalation can overload experts.

The sixth is monitoring intensity. High-risk domains need visible conflict, waiting, and override signals. Lower-risk domains may tolerate lighter measurement.

Invariants to Preserve

The most important invariant is that shared state remains internally consistent. Parallel speed is not success if it creates hidden corruption.

A second invariant is that shared resources are not double-allocated beyond intended capacity. The system must know when a resource has already been claimed, reserved, modified, or made unavailable.

A third invariant is that rules remain explicit and auditable. Concurrency failures become harder to repair when no one can reconstruct which actor had authority, which state was current, or why a conflict was resolved one way.

A fourth invariant is parallel progress where conflict is absent. Concurrency control should not turn the entire system into a serial queue unless that is genuinely required.

A fifth invariant is bounded waiting. Actors should not be blocked indefinitely without timeout, escalation, release, or recovery.

Target Outcomes

The primary outcome is safe parallel throughput: more work can overlap without corrupting what is shared. The system should become faster where work is independent and more disciplined where work is contested.

A second outcome is fewer timing-dependent incidents. Lost updates, duplicate claims, overbooked resources, inconsistent approvals, and race-like failures should become rarer or easier to catch.

A third outcome is clearer accountability. When conflicts occur, the system should show who acted, what state they saw, what rule applied, and how the conflict was resolved.

A fourth outcome is improved legitimacy. When people are affected by access priority, concurrency rules should be understandable enough to feel like procedure rather than arbitrary advantage.

Tradeoffs

Concurrency Control always trades some freedom for safety. Strong controls reduce risk but can reduce speed. Weak controls preserve speed but require monitoring and repair. The art is not to maximize control; it is to put control exactly where shared-surface conflict matters.

There is also a tradeoff between fairness and efficiency. A first-come rule may be efficient but not fair. A risk-based rule may be safer but harder to explain. A role-based rule may be clear but may concentrate authority.

Another tradeoff is local autonomy versus global consistency. Letting teams act independently can increase responsiveness, but shared state may require validation, reconciliation, or a single source of authority.

Failure Modes

Under-isolation occurs when actors can still interfere in ways the rule does not prevent. The mitigation is to remap shared state and strengthen isolation, ordering, or validation.

Over-serialization occurs when the control blocks work that could safely proceed. The mitigation is to narrow critical sections, partition work, or use optimistic validation.

Deadlock or livelock occurs when actors mutually wait or repeatedly retry without progress. The mitigation is to add ordering rules, timeouts, bounded retries, and escalation paths.

Starvation occurs when some actors repeatedly lose access. The mitigation is to add priority aging, fairness checks, or appeal paths.

Hidden shared state occurs when the design protects visible resources but misses downstream dependencies or social commitments. The mitigation is incident review and expansion of the shared-resource map.

Manual bypass normalization occurs when actors route around controls because they are too slow or obscure. The mitigation is to reduce unnecessary friction, align incentives, and make bypass visible.

Neighbor Distinctions

Concurrency Control is not the same as Transactional Atomicity. Atomicity asks whether one unit of work commits completely or not at all. Concurrency Control asks how multiple units of work overlap safely.

It is not the same as Deadlock Prevention. Deadlock is one failure mode inside concurrency; the broader archetype also covers races, overbooking, overwrites, duplicate action, and contested priority.

It is not Work-in-Progress Limiting. WIP limits reduce active load. Concurrency Control governs simultaneous interference over shared surfaces.

It is not Rate Limiting. Rate limiting caps arrival frequency; concurrency control governs overlap after work is active.

It is not Load Balancing. Load balancing distributes work across capacity; concurrency control protects shared resources and shared state from destructive overlap.

It is close to Conflict-Free Parallelism. The distinction is that Conflict-Free Parallelism tries to design away conflict through partitioning, ownership, commutativity, or idempotence. That makes it a strong variant or possible future archetype, but Concurrency Control remains the parent pattern for managing simultaneous interference.

Variants and Near Names

Conflict-Free Parallelism is preserved as a merge-review variant. It applies when the best control is to redesign work so parallel actions no longer contend. It may deserve promotion later if its components and examples remain distinct.

Race Condition Prevention is treated as a failure-mode variant. It names the case where the final outcome depends on accidental timing. The current draft keeps it under Concurrency Control because its interventions mostly use ordinary concurrency-control components.

Serialized Access Coordination is a subtype where the contested portion of work is intentionally sequenced. Locks, reservations, and facilitated turn-taking often instantiate this subtype.

Optimistic Concurrency Control is an implementation variant where actors proceed tentatively and validate before committing. It is useful when conflicts are rare and repair is possible.

Collaborative Concurrency Protocol is a human-work variant. It coordinates simultaneous edits, decisions, handoffs, or meetings where legitimacy and communication matter as much as technical correctness.

Near names include shared resource coordination, parallel access governance, concurrent work coordination, locking, mutexes, transaction isolation, and optimistic concurrency. Locks, mutexes, semaphores, and transaction isolation should remain mechanisms rather than standalone archetypes.

Cross-Domain Examples

In a database, two services update the same account balance. Concurrency control uses transaction isolation, version checks, or atomic updates so one service does not silently overwrite the other.

In collaborative writing, several authors work on a report. Ownership sections, change tracking, branch rules, and merge review allow parallel drafting without losing edits or producing contradictory sections.

In healthcare, multiple clinicians may issue orders for the same patient. Role-based confirmation, order status, handoff protocols, and conflict alerts prevent inconsistent treatment.

In maintenance operations, several crews need access to shared equipment. Lockout procedures, permit systems, and reservation windows coordinate safe access.

In a governance meeting, many participants share one procedural state. Turn-taking, motion order, amendment rules, and chair facilitation prevent simultaneous actions from creating ambiguity about what has been decided.

Non-Examples

A read-only archive accessed by many users is not a central case. Many concurrent reads do not necessarily create a shared-state conflict.

A team with too many independent projects is not automatically a concurrency-control problem. If projects do not touch the same resource or state, prioritization or WIP limits may be more relevant.

A simple service line is usually Queue Discipline Design, not Concurrency Control, unless simultaneous access to a shared resource creates additional interference.

A set of independent work packages that merge deterministically is closer to modular decomposition or conflict-free parallelism than to active concurrency control.