A big show goes on sale. In the first minute, hundreds of thousands of people all want the same few good seats. Two people cannot buy seat 12A. The system has to pick a winner, tell the loser instantly, and do it while absorbing a traffic spike that dwarfs its normal load. This is one of the cleanest examples of a concurrency problem in the wild, and the solution is a careful dance between locking, timeouts, and queues.
The core problem
A seat is a single unit of inventory that exactly one person can own. The moment you have shared mutable inventory and many concurrent buyers, you have a race. Two requests read "seat available", both proceed to buy, both succeed, and now two people are holding tickets to the same chair. Every wrong design of this system fails in exactly that spot: the gap between checking availability and claiming it.
The extra twist is that buying a ticket is not instant. A user selects seats, then spends a few minutes entering payment. During those minutes the seat cannot be sold to anyone else, but it also cannot be locked forever if they wander off.
Key design decisions
