Pessimistic vs Optimistic Locking: A Story-Based Explanation

In large distributed systems, concurrent writes are inevitable, and ensuring data consistency during simultaneous accesses is a core challenge.

The article tells a story about two threads, Wangcai and Xiao Qiang, who both need to reduce the stock of the same product, leading to lost updates when they write without coordination.

Wangcai proposes a solution: before accessing the inventory, acquire a lock that blocks other threads until the operation finishes, illustrating the concept of a pessimistic lock.

The narrative shows how the lock forces Xiao Qiang to wait, causing delays and potential bottlenecks, and notes that this approach assumes conflicts are likely, which can reduce overall concurrency.

Later, Wangcai introduces an optimistic lock: add a version field to the inventory record, read both stock and version, and when updating, check that the version has not changed; if it has, abort and retry.

The story demonstrates optimistic locking through a series of steps where Wangcai successfully updates the stock while Xiao Qiang encounters version mismatches, forcing him to reread and retry until he finally succeeds.

After the story, the article summarizes both mechanisms: pessimistic locking prevents conflicts by locking resources early, guaranteeing consistency but hurting performance and risking deadlocks; optimistic locking assumes conflicts are rare, allowing concurrent reads and writes and checking for conflicts only at commit time, which works well under low contention but may cause repeated retries under high contention.

Both methods are explained with concrete examples, and the article concludes that the choice between them depends on the expected conflict rate and performance requirements of the system.