Ticketing system design
Design the site where people find a show, pick their seats and buy tickets.
The problem
A ticketing site sells seats for concerts, plays and games.
You open a show, see the hall’s seat map, pick a seat and buy it: https://tickets.example/shows/1234
Each seat can be sold only once.
Questions to ask the interviewer
What is in scope?
- Show pages, the seat map, picking a seat and buying it.
- Not in this problem: refunds, resale, prices that change, the app for the hall staff.
How fast must it be?
Under 300 ms on average, for 99% of page views and seat picks.
How much traffic?
- 1,200 requests a second in the evening; 99% of them only look at shows and seat maps.
- Most people look many times before they buy: page views win.
How many seats?
The theatre has about 2,000 seats, and today few buyers want the same seat at once.
What must never happen?
Two people with a ticket for the same seat. A slow page is bad; a seat sold twice is worse.
What is the budget?
About $130 a month for the whole system.
Want to try it yourself first? Play, then come back for the approach.
PlayThe design in short
A ticketing site is two systems in one. Most visitors only look: show pages and seat maps, again and again. A few act: they pick a seat and buy it. The looking must be fast and cheap. The buying must be correct, every time.
The hard rule is one seat, one buyer. Two people must never get a ticket for the same seat. A slow page is bad; a seat sold twice is worse. So the buy path is where you spend your care. Before you draw it, say in plain words what must be true at the moment a seat is taken, and which part of your system is the judge.
Split the paths. Show pages change slowly. A seat map can be a little old, because the final check happens at the pick. So page views have room to be fast and cheap. Seat picks change the one true record of who owns a seat. Do not let the heavy read traffic slow down the writes that matter.
Where to focus on the board:
- the app machines serving page views and seat picks
- the database that holds the one true state of every seat
- where page views could be answered without going to that database
- what a buyer sees when someone else got the seat first
Reason about scale by path. Take the evening requests and split them by the share that only looks. The big share sizes the read path. The small share, seat picks a second, sizes the write path. Each path grows on its own, so check each one.
Ask the interviewer what is out of scope before you start: refunds, resale and changing prices each add a lot. Run your two paths in the game and look out for any seat sold twice.
Last updated 22 October 2026