System Design for an Online Event Ticketing Site: Seat Holds, Checkout and Spikes

Walk through how you would design the system behind a web application where people buy tickets to events. ```hint Find the scarce resource Browsing an event catalog is easy to scale. Think about what happens when many buyers want the same seat in the same second, and let that moment shape the design. ``` ### Clarifying Questions - Are seats assigned, so buyers pick a specific seat, or is it general admission, or do we need both? - Is this only the first sale from the organizer, or does it also include fans reselling tickets to each other? - What scale should I plan for: mostly small local events, or occasional on-sales where crowds far larger than the venue arrive at the same minute? - Do we process payments ourselves, or rely on an external payment provider? ### What a Strong Answer Covers - Functional scope and the non-functional requirements that matter most here: never selling a seat twice, fairness, and surviving on-sale spikes - A data model and API that separate browsing from reserving and paying - How a seat is held, paid for and released, including what happens when a payment or a server fails mid-checkout - How the system scales and stays fair when demand far exceeds supply, including defenses against bots - The product decisions that shape the design, such as hold length, purchase limits and seat selection, and the metrics used to run it ### Follow-up Questions - How would you add a resale marketplace without making life easier for scalpers? - A payment succeeds after the buyer's seat hold has expired. What should the system do? - How would you choose the length of the seat hold, and how would you test whether it is right?