Case Studies
Ticketmaster
Atomic seat holds under extreme on-sale contention, and why a read-then-write check loses to a conditional update.
Designing a system that sells a fixed number of seats to a much larger number of simultaneous buyers without ever selling the same seat twice — widely known in interview prep as "the Ticketmaster problem," after the real on-sale traffic spikes that make it a genuine concurrency problem rather than a CRUD one, and a good vehicle for testing whether a candidate reaches for an atomic check instead of a read-then-write.
What this lesson covers
Hold a seat with one atomic conditional update (UPDATE WHERE status = 'available' or Redis SET NX EX), never a read-then-write check; the hold's TTL auto-releases it, and payment must confirm before expiry. Optimistic beats a per-seat lock: a race loser is told unavailable.
- Musical chairs with ten thousand chairs and a million players: almost all demand lands in the first seconds of an on-sale.
- Let a user hold a seat while they check out, release it automatically on timeout, and guarantee exactly one owner under contention.
- A read-then-write availability check has a race; the fix is an atomic conditional check, and knowing why is the core signal.
- Optimistic versus pessimistic locking is a real trade-off here, not a default: contention is intense but brief per seat.
- Staff answers add admission control for the spike itself, such as a fairness-preserving virtual queue paced to seat clearing.
Included in Plus and Pro
Continue reading “Ticketmaster”
The full lesson works the design through end to end — diagrams, trade-offs, and what interviewers expect at each level. About 18 minutes.
- Understanding the Problem
- Functional Requirements
- Non-Functional Requirements
- Capacity Estimation
- Core Entities
- API Interface
- High-Level Design
- Trade-offs
- Final Design
- Operations & Observability
- Level Expectations
- Follow-Up Questions
- Try It Yourself