Booking & concurrency

Design Ticketmaster

Hard

Sell 50,000 seats to 500,000 fans in 60 seconds — without ever double-selling one.

Ticketmaster is an online ticketing platform: fans browse events, pick seats, and buy tickets. What makes it a hard system-design problem is the flash sale — when a stadium tour goes on sale, hundreds of thousands of fans hit the exact same tiny pool of seats in the same minute.

Two forces pull in opposite directions:

Browsing is read-heavy and wants availability — event pages must stay fast even under load.
Buying is write-heavy on a hot spot and wants strong consistency — a seat must be sold to exactly one person.

The whole design is about keeping those two paths separate and picking the right consistency model for each. This is the canonical "strong consistency under contention" interview.

Start by scoping. The interviewer wants to see you separate the read path (browse) from the write path (reserve + buy) early — that split drives every later decision. Keep the functional list to the handful you'd actually build in 45 minutes; the virtual waiting room that shapes onsale load is a mechanism you'll introduce in the deep dive, not a separate feature.

Functional

Browse events and view an event's seat map with live availability.
Reserve/hold seats temporarily while the fan enters payment.A hold expires after a TTL (~10 min) so abandoned carts free the seat.
Purchase held seats — charge payment, then mark seats permanently sold.
Never double-sell a seat: one seat → at most one confirmed order.

Non-functional

Strong consistency on inventory — a sold seat is never offered again (correctness over availability on the write path).
High availability for browse — event pages target 99.95%+ and survive spikes.
Flash-sale scale — a hot event: ~200k fans contending for ~50k seats in the first minute.
Low latency — browse < 200 ms p99; reserve < 500 ms p99.
Fairness — no fan is starved; first-come-first-served-ish, bot-resistant.

Out of scope

Dynamic/surge pricing
Fraud & bot ML detection
Secondary resale marketplace
Order-history views & recommendations

Check yourself· 3 questions

Question 1

Which single invariant is the hardest part of this system and shapes the whole write path?

Question 2

Why hold a seat with a TTL instead of only marking it sold at payment time?

Question 3

Which requirement most justifies a virtual waiting room in front of the buy path?