# 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? ```hint Model the seat state Write explicit available, held, and sold transitions with conditional versions and expiry. ``` ```hint Treat payment timeout as unknown Query or reconcile by idempotency key instead of immediately charging again. ``` ### What a Strong Answer Covers - Clear service and data boundaries for catalog, inventory, holds, orders, and payment. - An atomic seat state transition and expiry mechanism. - A surge-control strategy that includes fairness and protects the inventory store. - Idempotency, payment reconciliation, cache policy, observability, and recovery. ### 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?