Picture two users withdrawing money from the same bank account at the exact same moment. Each one reads a balance of 100, each subtracts their amount, and each writes the result back. If User A withdraws 30 and User B withdraws 50, the correct final balance is 20. But because both read the same starting value, whichever write lands last simply overwrites the other. The balance ends up at either 70 or 50 -- never 20. This is the **lost update problem**, and it is the most common form of a race condition. Every system that allows concurrent modifications to shared state -- a bank balance, a seat reservation, a chess board, an inventory count -- must deal with it explicitly. The root cause is always the same: a **read-modify-write** cycle that is not atomic. The gap between reading and writing creates a window where another operation can slip in and invalidate the assumption your computation was based on. Every strategy in this article is a different way to close that gap. ## Optimistic Concurrency Control (OCC) Optimistic locking bets that conflicts are rare. Instead of preventing concurrent access, it detects conflicts at write time and retries when they happen. The mechanism is simple: every row carries a **version number** (or a timestamp, or a hash). When you read the row, you note the version. When you write, you include the version in a conditional update: ```sql UPDATE accounts SET balance = 70, version = 8 WHERE id = 123 AND version = 7; ``` If another transaction modified the row first, the version is no longer 7, the WHERE clause matches zero rows, and your update silently does nothing. Your application checks the affected-row count, sees zero, re-reads the latest value, recomputes, and tries again. **When it works well:** Read-heavy workloads where conflicts are infrequent. If only 1 in 1,000 writes actually collides, the retry cost is negligible and you avoid the overhead of locking entirely. **When it breaks down:** Under high contention, retries pile up. If 50 transactions are trying to update the same row simultaneously, 49 of them fail and retry, then 48 fail again, and so on. This "retry storm" wastes CPU and can actually make throughput worse than simple locking would. **See it in practice:** In [Online Chess](/learn/system-design/questions/online-chess), two players submitting moves at the same instant need version checks on the board state to prevent one move from overwriting the other. In [Google Calendar](/learn/system-design/questions/google-calendar), overlapping event creation on the same time slot uses optimistic concurrency to detect and reject double-bookings. The [Payment Systems](/learn/system-design/design-patterns/payment-systems-financial-consistency) pattern covers how financial systems combine OCC with idempotency keys to prevent duplicate charges. ## Pessimistic Locking Pessimistic locking takes the opposite bet: conflicts are expected, so prevent them upfront. You acquire an exclusive lock on the resource before reading it, guaranteeing no one else can touch it until you are done. In SQL, this is `SELECT ... FOR UPDATE`: ```sql BEGIN; SELECT balance FROM accounts WHERE id = 123 FOR UPDATE; -- lock acquired; other transactions block here UPDATE accounts SET balance = balance - 50 WHERE id = 123; COMMIT; -- lock released ``` Between the SELECT FOR UPDATE and COMMIT, any other transaction trying to read or write the same row will **wait**. There are no retries, no version checks -- concurrency is eliminated by serialization. **When it works well:** High-contention scenarios with short-lived transactions. If you know many requests will hit the same row, acquiring a lock upfront is cheaper than the retry storms that optimistic locking would produce. **When it breaks down:** Long-held locks kill throughput -- other transactions queue up behind the lock holder. And if two transactions lock resources in different orders (Transaction A locks row 1 then tries row 2, while Transaction B locks row 2 then tries row 1), you get a **deadlock**. Databases detect deadlocks and abort one transaction, but this adds complexity and unpredictability. **See it in practice:** In [Bookstore](/learn/system-design/questions/bookstore), inventory decrement during checkout uses `FOR UPDATE` to prevent overselling when multiple buyers purchase the last copy simultaneously. In [Job Scheduler](/learn/system-design/questions/job-scheduler), worker nodes compete to claim jobs from a shared queue -- pessimistic locking ensures exactly one worker picks up each job. The [Idempotency and Exactly-Once](/learn/system-design/design-patterns/idempotency-exactly-once) pattern explains how to combine locking with idempotency tokens for safe retries. ## Atomic Operations For simple numeric updates, you can skip the read-modify-write cycle entirely. Instead of reading a value, computing locally, and writing back, you let the database or cache engine do the modification in a single atomic step. SQL supports this directly: ```sql UPDATE accounts SET balance = balance - 50 WHERE id = 123; ``` Redis provides INCR, DECR, and INCRBY for the same purpose. These operations are atomic at the storage layer -- the engine handles serialization internally, so no application-level lock or version check is needed. **When it works well:** Counters, balances, stock quantities -- any operation that can be expressed as "add X to the current value" without needing to read the current value first. **When it breaks down:** Complex business logic cannot be expressed as a single atomic operation. If you need to validate that the balance is sufficient before withdrawing (reject if the balance would go negative), you need a conditional check, which brings you back to one of the locking strategies above. **See it in practice:** In [Distributed Counters](/learn/system-design/questions/distributed-counters), the entire design revolves around atomic increments under extreme concurrency -- Redis INCRBY handles millions of counter updates per second without locks. In [Ads Click Aggregator](/learn/system-design/questions/adds-click-aggregator), click counts are atomically incremented in real time and periodically flushed to persistent storage. In [Leaderboard](/learn/system-design/questions/leaderboard), Redis sorted sets use atomic ZINCRBY to update player scores without read-modify-write races. ## Compare-and-Swap (CAS) Compare-and-swap is a generalization of optimistic concurrency that works beyond databases. The pattern is a tight loop: read the current value, compute the new value, then attempt a conditional write that only succeeds if the value has not changed since you read it. If it changed, retry from the top. CAS is the foundation of **lock-free data structures** used in high-performance systems. CPUs expose CAS as a hardware instruction (CMPXCHG on x86). DynamoDB exposes it through conditional writes. ZooKeeper exposes it through versioned setData operations. Etcd exposes it through transactions with version predicates. The key advantage over database-level optimistic locking is that CAS works in any storage system that supports conditional writes -- you are not limited to SQL databases. The disadvantage is the same: under high contention, the retry loop burns CPU. **See it in practice:** In [Distributed Counters](/learn/system-design/questions/distributed-counters), CAS loops power lock-free counter updates in DynamoDB using conditional expressions. In [Online Chess](/learn/system-design/questions/online-chess), board state transitions use compare-and-swap to ensure moves are applied to the expected game state. The [Unique ID Generation](/learn/system-design/design-patterns/unique-id-generation) pattern uses CAS-style atomic counters for sequence allocation without coordination. ## Distributed Locks When the resource spans multiple services or when there is no shared database to lean on, you need a lock that works across machines. This is a **distributed lock**. The simplest implementation uses Redis SET with the NX (set-if-not-exists) and PX (expire in milliseconds) flags: ``` SET lock:account:123 "owner-uuid" NX PX 30000 ``` If the key does not exist, it is created and the caller holds the lock. If it already exists, the command returns nil and the caller knows someone else holds it. The PX 30000 ensures the lock auto-expires in 30 seconds so a crashed lock holder does not block everyone forever. ### The Fencing Problem There is a subtle danger: what if the lock holder takes longer than 30 seconds? The lock expires, another instance acquires it, and now two instances think they hold the lock. To prevent this, use **fencing tokens** -- a monotonically increasing number issued with each lock acquisition. The shared resource rejects any request carrying a fencing token lower than the highest one it has already seen. ### Redlock for Stronger Guarantees A single Redis node is a single point of failure. The **Redlock algorithm** acquires the lock on a majority of independent Redis nodes (e.g., 3 of 5). This tolerates individual node failures without losing the lock's safety guarantee. The trade-off is higher latency (you need to talk to multiple nodes) and added operational complexity. **See it in practice:** In [Payment](/learn/system-design/questions/payment), distributed locks prevent double-charging when a payment retry arrives at a different service instance than the original. In [CICD](/learn/system-design/questions/cicd), build locks ensure only one pipeline deploys to a given environment at a time. The [Managing Long-Running Tasks](/learn/system-design/design-patterns/managing-long-running-tasks) pattern uses distributed locks to prevent duplicate task execution across worker nodes. ## Queue-Based Serialization The most radical approach: eliminate concurrency entirely. Instead of letting multiple processes access the resource simultaneously and resolving conflicts, route all operations for a given resource through a **single queue partition**. A single consumer processes them one at a time, in order. No locks, no version checks, no retries -- contention is impossible because operations are sequential by design. The implementation typically uses Kafka or a similar message broker. You partition by resource ID (e.g., account number, game ID), which guarantees that all operations for the same resource land in the same partition and are processed by the same consumer in order. **When it works well:** When operation ordering matters more than immediate response. Event sourcing systems, financial ledgers, and game state machines all benefit from strict sequential processing. **When it breaks down:** Latency increases because every operation waits in line. Throughput is capped by the speed of the single consumer. If you need sub-millisecond response times or handle thousands of updates per second to the *same* resource, queue serialization may be too slow. **See it in practice:** In [Online Chess](/learn/system-design/questions/online-chess), move submissions can be serialized through a per-game queue to guarantee moves are applied in order without race conditions. In [Slack](/learn/system-design/questions/slack), message ordering within a channel is preserved by partitioning the message queue by channel ID. The [Event Sourcing and CQRS](/learn/system-design/design-patterns/event-sourcing-cqrs) pattern builds on queue serialization to create an append-only event log as the source of truth. The [Pub/Sub Messaging](/learn/system-design/design-patterns/pub-sub-messaging) pattern covers Kafka partitioning and consumer group mechanics in detail. ## Trade-off Comparison ## Distributed Systems: When Things Get Harder In a single database, ACID transactions handle contention naturally -- SELECT ... FOR UPDATE just works because there is one source of truth. Once you **shard** data across multiple databases, you lose cross-shard ACID guarantees. Two updates to different shards cannot be wrapped in a single transaction. **Two-phase commit (2PC)** restores atomicity across shards: a coordinator asks all participants to prepare, then tells all to commit (or all to abort). But 2PC introduces a coordinator bottleneck, adds two network round trips of latency, and blocks participants if the coordinator crashes mid-protocol. The pragmatic solution is to design your shard keys so that contending operations land on the **same shard**. If two users are modifying the same chess game, partition by game ID so the entire game lives on one shard. If two requests are withdrawing from the same account, partition by account ID. This eliminates cross-shard coordination entirely. When cross-shard coordination is truly unavoidable, consider the [Sagas](/learn/system-design/design-patterns/multi-step-processes-sagas) pattern, which breaks a distributed operation into a sequence of local transactions with compensating actions for rollback. **See it in practice:** In [Payment](/learn/system-design/questions/payment), a single purchase may need to debit one account and credit another on different shards -- sagas with compensation handle the distributed coordination. In [Uber](/learn/system-design/questions/uber), ride state is partitioned by ride ID so that all updates to a single ride hit the same shard without cross-shard locks. The [Scaling Writes](/learn/system-design/design-patterns/scaling-writes) pattern covers sharding strategies, consistent hashing, and hot-shard mitigation in depth.