Design a High-Demand Ticketing System
AirwallexSoftware Engineer · Technical ScreenLast updated
Design a ticketing system for high-demand events. Connect requirements and APIs to data modeling, consistency, scaling, failure recovery, observability, and the important design trade-offs.
Design a High-Demand Ticketing System
Design a ticketing system for high-demand events. Users should discover events, view seat or section availability, temporarily hold inventory, complete payment, and receive an order without selling the same seat twice. Cover the surge when sales open and explain the trade-offs in inventory consistency, queues, caching, and failure recovery.
Constraints & Assumptions
- Reserved seats must never be confirmed to two orders.
- A hold expires if checkout is not completed within a configured interval.
- Search and event details may be eventually consistent; checkout inventory may not.
- Payment providers can time out after charging, so ambiguous outcomes are possible.
Clarifying Questions to Ask
- Are seats assigned individually or sold as general-admission quantities?
- What traffic and fairness behavior are expected when sales open?
- Can users select exact seats, and may a hold contain adjacent-seat constraints?
Hints
Hint 1
Model the seat state: Write explicit available, held, and sold transitions with conditional versions and expiry.
Hint 2
Treat payment timeout as unknown: Query or reconcile by idempotency key instead of immediately charging again.
Follow-up questions
- How would you support best-available allocation for a group that wants adjacent seats?
- How would you prove that an expired hold cannot race with a late successful payment?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.