Design a Ticket Booking Service
Fans buy seats for concerts. When a popular show goes on sale far more people arrive than there are seats, so buyers wait in a line and are let in one at a time in the order they arrived. A seat can only be sold once: it is held for a few minutes while the buyer pays through an outside processor, and released if they do not.
Constraints
- Browsing seats must respond within 250 ms
- About 4,000 requests per second normally, and a hot on-sale makes the demand to buy several times higher
- A seat can never be sold to two people
- Buyers are admitted from the waiting line in the order they arrived
- Payment goes through an external processor, and a failed or abandoned payment releases the seat
- Keep infrastructure under $8,000 a month
- About 4 million seats are on sale across 2,000 events
Scenarios to survive
Typical day
Steady browsing and a normal rate of purchases.
Interviewer asks: Browsing and buying have very different needs. How do you stop a rush of buyers from slowing down people who are just looking?
A hot on-sale
Three times the traffic, and holds, payments and the waiting line are several times busier still.
Interviewer asks: More people want seats than exist. What limits how fast you let buyers through, and what happens to the rest?
Payment processor outage
The external payment processor stops answering.
Interviewer asks: Payments cannot go through. What happens to held seats and to buyers who are mid-checkout?
Seat database loses a node
The database holding seat holds loses a node.
Interviewer asks: The seat store loses a node. Can you still guarantee no seat is sold twice?
What a good design must do
- Browsing meets the latency target at peak
- The hot on-sale passes
- Total monthly cost stays within $8,000
- Buyers are admitted through a Stream, in arrival order
- Something holds seats, and never to two buyers
- Something takes payment
- Something releases expired holds
- Browsing keeps working when the payment processor is down
- The design explains how the waiting line stays fair
- Every query is answered through a key or an index, never by reading a whole table