Designing Ticketmaster — Seat Reservation Without Double-Booking, Traced
The hard part of ticketing isn't scale — it's not double-selling
At a hot on-sale, thousands hit the same seats in the same second. The system must guarantee a seat is sold
at most once. This is the concurrency lesson (lost update / write-write conflict) made
business-critical — the same race as counter++ and DB isolation
anomalies, now worth real money.
The race, and three ways to prevent it
Without protection: both buyers SELECT seat 5A, both see "available", both UPDATE it
booked → double-booked. Fixes:
- Pessimistic lock —
SELECT … FOR UPDATEon the seat row; the second buyer blocks, then sees it booked (the traced flow in the diagram). Simple and correct; holds a lock. - Short-lived reservation — mark the seat "held" with a TTL while the buyer pays; release if they don't complete. Avoids long locks during slow payment.
- Optimistic —
UPDATE … SET booked=1 WHERE id=5A AND booked=0; if 0 rows changed, someone beat you (a CAS in SQL). Great under low contention.
Scaling the flash sale
- Virtual waiting room — admit users in controlled batches so the booking tier isn't stampeded (see Rate Limiting).
- Inventory in Redis with an atomic decrement for fast "is anything left?" checks, reconciled to the durable DB which is the source of truth for the actual seat.
- Idempotent booking — a client retry (timeout, double-click) must not book twice; key the request with an idempotency token.
Pitfalls
- Holding the DB lock through payment (seconds) kills throughput — use a held-reservation with TTL instead.
- Overselling if you trust an eventually-consistent cache as the source of truth — the DB row is authoritative.
- Retries without idempotency → duplicate bookings/charges.
Takeaways
- Core requirement: never double-sell — serialize on the seat (FOR UPDATE / held-reservation / optimistic CAS).
- Don't hold locks across payment; use a TTL reservation; the DB is the source of truth.
- Flash-sale scale = waiting room + Redis inventory + idempotent bookings.
Re-authored for this guide; seat-lock timeline hand-authored as SVG. See also: (Databases) Isolation Levels & MVCC, Rate Limiting, Idempotency. (Complements the existing "Designing Ticketmaster" problem page.)
🤖 Don't fully get this? Learn it with Claude
Stuck on Designing Ticketmaster — Seat Reservation Without Double-Booking, Traced? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Designing Ticketmaster — Seat Reservation Without Double-Booking, Traced** (System Design) and want to truly understand it. Explain Designing Ticketmaster — Seat Reservation Without Double-Booking, Traced from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **Designing Ticketmaster — Seat Reservation Without Double-Booking, Traced** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **Designing Ticketmaster — Seat Reservation Without Double-Booking, Traced** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **Designing Ticketmaster — Seat Reservation Without Double-Booking, Traced** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.