System Design Interview
Concert ticketing for flash on-sales, inspired by Ticketmaster and similar platforms: CDN event pages, atomic seat holds in memory, a virtual waiting room, background payment with hold expiry, and bot protection. A teaching design.
See what a concert on-sale does to one server and one database.
What was missing: Nothing yet.
Why that's risky: At on-sale time hundreds of thousands of fans arrive in seconds; every page view, search and seat attempt hits one database, which locks up while scalper bots grab seats.
What gets added: One server that serves pages, searches and books seats in one database.
Trade-offs: Fine for a small venue, hopeless for a stadium tour.
Take everything that isn't buying a seat away from the database.
What was missing: Pages, search and booking all hit the same database.
Why that's risky: Every seat attempt is a database transaction on a handful of hot rows, so lock contention collapses throughput exactly when demand peaks.
What gets added: A CDN for event pages and static files; an event catalog database for events, venues, seat layouts and prices; an event search service and index kept up to date by an indexer as seats sell; and a booking service that takes a seat with a conditional update in the inventory database.
Trade-offs: The search index shows remaining availability a few seconds behind sales, because the indexer updates it from a queue.
Absorb thousands of simultaneous seat grabs without locking database rows.
What was missing: Every seat attempt locked database rows.
Why that's risky: Every fan still hits the hold service at the same instant, and whoever has the fastest connection or script wins.
What gets added: An inventory cache where a hold is an atomic set-if-free with an 8-minute timer, a seat map service that draws the venue layout with live seat status from that cache, a hold service in front of it, and a checkout service that turns a hold into a booking with a conditional update in the sharded inventory database.
Trade-offs: The cache is fast but not the source of truth: the database's conditional update on purchase is the final guard against overselling.
Turn a stampede into an orderly line that admits fans at a rate the system can handle.
What was missing: Everyone hit seat selection at the same moment.
Why that's risky: Checkout still charges cards synchronously, and seats from abandoned checkouts aren't given back.
What gets added: A waiting room service: at on-sale everyone gets a random place in line, and fans are admitted at a fixed rate with a signed token that the hold service checks against the queue position cache before it holds any seat.
Trade-offs: Fans wait in line, sometimes for many minutes, in exchange for a site that stays up and a fair order.
Charge reliably without blocking seats, and recycle abandoned holds.
What was missing: Charging blocked checkout, and abandoned holds never returned to sale.
Why that's risky: Bots can still hammer the waiting room and seat map, and nobody watches oversell checks or admission rate.
What gets added: Payment jobs processed by workers that charge with an idempotency key and mark the seats sold, ticket delivery jobs that email the tickets and add them to the fan’s account, and delayed expiry jobs that release unpaid holds back to the line.
Trade-offs: Tickets arrive seconds after checkout instead of instantly.
Keep scalper bots out and watch the on-sale live.
What was missing: Nothing distinguished bots from fans, and the on-sale was invisible.
Why that's risky: Remaining risk is account farms that look human; that needs verified-fan programs on top of rate limits.
What gets added: A bot shield at the edge, in front of the load balancer, with per-account and per-IP limits and challenges for suspicious clients, ticket limits per account, and monitoring of admission rate, line length, hold conversion, oversell checks and payment failures.
Trade-offs: Challenges add friction for some real fans.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
