How the interviewer opens it
“Design a ticket booking system like Ticketmaster where people browse events and buy seats.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- scale
- seat holds
- consistency
- payments
- fairness
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- View an event and seat map
- Hold seats during checkout
- Purchase without double-selling
Usually out of scope
- Event creation by organizers
- Resale marketplace
- Building the payment processor
What interviewers probe
- Preventing double booking
- Check-then-act races under extreme contention.
- Flash-sale traffic
- 10M users arrive in seconds for a tiny inventory.
- Payment failure handling
- External provider timeouts leave unknown states.
Common mistakes
- No hold concept
- Trusting cached availability for booking
- No idempotency on payment
- No admission control for on-sales
The bar by level
- Senior (L5/E5)
- Locking strategy trade-offs, hold expiry, payment idempotency/reconciliation, caching seat maps, admission control.
- Staff (L6+/E6+)
- Fairness and bot strategy, multi-region inventory ownership, failure drills for on-sales, cost of pre-scaling vs shedding.