Design interviews / Intermediate / 6 min
Design ticket booking: two people, one seat
Fans race for the centre seats. No lock sells seats twice, checking at payment means refunds, and seat holds with a timer fix both.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A booking system lets many people race for specific seats, holding a chosen seat for a short time while the buyer pays.
- Why it matters
- Popular shows get thousands of clicks on the same seats in seconds, and selling one seat twice is unacceptable.
- The trade-off
- Short holds free seats fast but cut off slow payers; long holds are kind to payers but block seats of people who left.
- Say it in an interview
- "Seat hold as an atomic conditional write (Redis SET NX EX or UPDATE … WHERE status=free) with a TTL, payment within the hold, then a final conditional book; a queue in front for huge on-sales."
Check yourself
How can the same seat be sold twice?
Answer: Two buyers both see it free, both pay, and both writes succeed because nothing locked the seat. Check-then-act without a lock or conditional write is a race condition.
What does a seat hold with a timer give buyers?
Answer: The seat is reserved while they pay, so nobody else can pick it, and it frees itself if they leave. The hold is an atomic, expiring lock (e.g. Redis SET NX with TTL or a row with an expiry).
What is the problem with a very short hold?
Answer: Slow payers lose the seat mid-payment and may need a refund. Too short punishes real buyers; too long blocks seats of people who left. Typical holds are 5 to 10 minutes.