The last vada (inventory contention and locking)

The shelf of books a system keeps its facts in. This lesson opens one of them at a single line, the one that says how many vadas are left, and asks what happens when fifty people write on it at once.

Before you start. From The Right Book for the Job (databases, deeply) you need the book itself: the database, where the stall writes its facts down and reads them back, and which can bundle a few reads and writes into one all-or-nothing unit called a transaction. Transactions showed two such units reading the same line and both writing from it, so one write silently erased the other; The Two Ledgers Must Agree (Distributed Transactions) showed a lock left down by a helper who vanished, freezing everyone behind it; and Charged Twice (idempotency & exactly-once) showed that a retried request must carry one name for one intent, so the second try is not a second charge. Each comes back when it is needed.

The idea in 30 seconds

A race condition is a bug where the result depends on timing: several requests read the same value, each decides from it, and each writes, so the later writes erase the earlier ones.
A lock makes buyers take turns on an item’s record; it never oversells, and the cost is waiting, plus a frozen item if the holder dies.
Optimistic concurrency lets everyone read and writes only if a version number is unchanged; it is cheap when buyers rarely clash and wastes work on retries when many chase one item.
Sending every request for one item through a single queue with one worker cannot oversell either, but the queue serves at one worker’s pace, so waiting grows with the crowd.
A hold sets an item aside while the buyer pays, and its TTL, time to live, returns it to stock if payment never comes.

Read the story · Skip to the numbers