Seat Hold Reservation Lab (Interactive)
Release a fan lobby onto 60,000 seats and compare guarded UPDATEs to oversell races. Model ticket hold contention with a virtual-waiting-room gate, hold TTL expiry, and connection-pool saturation under a fan release.
Ticketmaster-style Seat Hold Lifecycle (60,000 seats)
500k fans hit one venue at once. Throttle them at a Virtual Waiting Room, then let atomic conditional UPDATEs settle who gets seats.
› On sale at 10:00:00 — lobby holds 500k users at the edge.
Zero double-booking comes from one SQL shape: UPDATE seats SET status='HELD' WHERE section_id=? AND row_no=? AND col_no=? AND status='AVAILABLE' — of 1,000 simultaneous transactions exactly one sees affected_rows=1. The 3-state lifecycle AVAILABLE→HELD(10-min Redis SET NX PX 600000 + DB row)→SOLD auto-releases abandons, which is how scalpers' carts expire. The waiting room's signed X-Waiting-Room-Token serializes a 500k lobby into the ~1,000 QPS the database can actually serve.
How It Works Under the Hood
Popular on-sales slam thousands of users onto a finite seat map, and the system must never oversell. The core trick is making the reservation itself atomic: a conditional UPDATE with a WHERE seat_status = available clause reports affected_rows, so only the first racer flips a seat and everyone else gets zero rows — no double booking. A virtual waiting room gates the lobby so only as many users hit the database as the connection pool can absorb, and holds carry a short TTL that auto-expire and return seats to inventory if checkout stalls. Release a fan wave and compare guarded updates to a naive read-then-write that oversells.
Core Architectural Principles
- Conditional UPDATE affected_rows: 1 means you won the seat, 0 means someone beat you — oversell-proof.
- A virtual waiting room admits only pool-sized concurrency, for example 200 database connections.
- Holds expire after a TTL and return seats to the available pool when you advance the clock.
Lead with oversell as the hard correctness requirement and answer with an atomic conditional update or row lock, not application-level check-then-act. Discuss the waiting room as admission control against DB connection limits, short reservation TTLs with auto-release, and idempotency on the checkout. Mention partitioning the seat map by section and pre-warming inventory into cache.
Row-level locks guarantee no oversell but throttle throughput, while optimistic conditional updates scale better yet must retry on contention.