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 search service and index, and a booking service that takes a seat with a conditional update in the database.
Trade-offs: The search index shows remaining availability with a short delay.
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 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 requires.
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 and ticketing jobs processed by workers that charge with an idempotency key and issue tickets, 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 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:
