Who Gets the Last Seat? Race Conditions Explained
Concurrent purchase requests are serialized by locks or ordering rules, so the winner is determined by which request first acquires exclusive access—not by who clicked first in human time.
A complete interactive classroom, not just a preview.
Start when you are ready to enter this Stage's 9 scenes and explore, respond, and learn as you go.
When two people tap 'buy' at the same instant, how does the system decide who gets the item?
Two shoppers click 'buy' at the exact same millisecond—and only one gets the concert ticket. Who loses, and why?
It feels unfair that timing alone decides, but the alternative is selling the same seat twice. The system must choose a winner, and the rule it picks determines who that winner is.
A simulation showing two concurrent requests racing through a queue, plus a diagram of locking and ordering.
Computers don't 'see' who clicked first—they sequence requests by ordering rules, and the first request to acquire the lock wins.
The person who clicked a split-second earlier should win, because the system must have a way to detect who pressed first.
- Front-end UI lag compensation
- Payment authorization and fraud scoring
- Queueing theory at scale (load balancers, sharding)
- CAP theorem and distributed consensus algorithms
- 01The Simultaneous Click ProblemslideQuestion
Open with two devices showing the same item in stock, both about to tap 'buy'. Pose the driving question visually.
- Two users, one item, one millisecond
- Who gets it? Who decides?
- Human intuition vs. machine reality
- 02Commit to Your GuessquizPrediction
Ask the learner to predict the rule the system uses before any explanation is shown.
- Reveal an intuition worth testing
- 03Race the Two RequestsinteractiveEvidence
A simulation where two 'buy' requests hit an inventory counter at the same moment. The learner runs the race and watches requests interleave.
- Both requests read stock = 1
- Without coordination, both write stock = 0
- Overselling happens every time
- 04The Visible Result: OversellingslideEvidence
Show the timeline of reads and writes overlapping, producing two confirmed sales for one item.
- Read–modify–write is not atomic
- Two sellers, one seat
- Why 'fast' isn't enough
- 05Add a LockinteractiveExplanation
Re-run the same race but with a mutex/lock around the inventory check. The learner sees requests serialize and only one wins.
- Lock blocks the second request until the first finishes
- Order is now deterministic
- Loser sees 'sold out'
- 06Why the Lock Beats Click TimeslideExplanation
Explain that the system never compares human timestamps; it arbitrates at the moment of the write. Show the lock as a single doorway.
- No clock compares the two clicks
- The lock is the arbiter
- First to acquire the lock wins; order is arbitrary but deterministic
- 07When the Lock BreaksslideBoundary
Show what happens when the database and the app server disagree—a brief boundary case to prevent overgeneralization.
- Locks live in one place; distributed systems need more
- Optimistic vs. pessimistic locking
- Atomic compare-and-set as an alternative
- 08Apply It: Hotel BookinginteractiveTransfer
Transfer the idea: two guests try to book the last hotel room. The learner toggles locking on/off and predicts the outcome.
- Same race, different domain
- Lock on → one guest confirmed, one waitlisted
- No lock → both confirmed, hotel overbooked
- 09The AnswerslideResolution
Directly answer the driving question and close the loop on the opening tension.
- The system doesn't know who clicked first
- A lock serializes the requests
- First to acquire the lock wins; the other sees 'sold out'
- Fairness is a separate engineering choice, not a default
Discussion threads for a Stage aren't available yet.
