# Design a High-Demand Event Ticket Marketplace Design an online marketplace for event tickets. Users search events, view seat availability and prices, place a short-lived hold on selected inventory, pay, and receive a confirmed order. Popular onsales can create sudden traffic spikes, but the system must not sell the same uniquely assigned seat twice. ### Constraints & Assumptions - Inventory may contain assigned seats and general-admission quantities. - Search can be eventually consistent; reservation and purchase correctness cannot. - Payment calls can time out or return asynchronous results. - Holds expire automatically and must release inventory safely. - Bots, abuse, and unfair queue bypass are material operational concerns. ### Clarifying Questions to Ask - Are resale, transfers, refunds, or dynamic pricing in scope? - How long should holds last, and may users extend them? - Is waiting-room fairness required for every event or only high-demand releases? - What availability and regional requirements apply to checkout? ### Part 1: Inventory and Checkout Define the inventory, hold, order, and payment state machines and the APIs that connect them. #### What This Part Should Cover - Atomic seat or quantity reservation with a stable hold ID and expiry. - Idempotent checkout and payment-attempt handling. - Clear transitions among available, held, sold, expired, canceled, and uncertain payment states. ### Part 2: High-Demand Traffic Explain how search, event pages, waiting rooms, admission control, and reservation capacity behave during a spike. #### What This Part Should Cover - Cached read models that never authorize a sale. - Bounded admission to the correctness-critical inventory path. - Fairness tokens, rate limits, bot controls, and backpressure. ### Part 3: Failure Recovery and Operations Address expiry, duplicate messages, reconciliation, testing, and metrics. #### What This Part Should Cover - Fenced expiry jobs so a stale timer cannot release a renewed or sold hold. - Reconciliation among inventory, orders, and payments. - Concurrency and fault tests for the no-oversell invariant. - Metrics for holds, checkout, queues, payment uncertainty, and inventory mismatch. ### What a Strong Answer Covers - Strongly controlled inventory mutation and explicit state machines. - Separation between scalable stale reads and authoritative reservation writes. - Honest treatment of payment uncertainty, retries, and reconciliation. - Load shedding and fairness that protect correctness during demand spikes. ### Follow-up Questions - How would general-admission inventory differ from assigned-seat locking? - How would you recover a payment that succeeded after its hold appeared to expire? - How would you prove that a waiting-room token cannot be replayed?