Design Ticketmaster
Problem Statement
Design the client-facing architecture for an event ticketing product: discovering events, picking specific seats out of a 20,000-seat venue map, holding those seats while the user pays, and converting a hold into a confirmed order without ever double-selling a seat or double-charging a card.
This walkthrough follows the Product Architecture framework and assumes you have read it, since the framework already uses Ticketmaster as its running example. Everything here lives above the API contract: what the client renders, what it stores, what it asks for, and what it does when the answer is "those seats are gone."
The hardest thing in this problem is not the seat map. It is that the seat map cannot promise anything. Inventory is contested by tens of thousands of people at once, so every pixel the client draws is a snapshot that may already be wrong. Build the design around one authoritative call, POST /holds, and treat everything else as advisory.
The System Design round asks a structurally similar question about inventory and holds: see Hotel Booking System. That round spends its time on how the hold is stored and how the inventory service scales. This round spends its time on how the client renders contested inventory, how it recovers when a hold fails, and how the contract keeps a retry from becoming a second purchase.
Common Aliases
- Design an event ticketing platform
- Design a concert or sports ticket booking app
- Design StubHub or SeatGeek
- Frontend system design: seat selection and reservation
- Design a seat map picker with concurrent booking
Level Calibration
The same prompt is graded differently by level. The framework splits breadth and depth 80/20 at mid, 60/40 at senior, 40/60 at staff.
| Level | What a complete answer looks like |
|---|---|
| Mid-level | The six core endpoints, the split between immutable geometry and hot availability, and one flow walked end to end from GET /events/{id} through POST /holds to POST /orders. That is a complete pass. |
| Senior | All of that, plus the hold state machine as explicit states (Selecting, Requesting, Held, Expiring, Expired, Converting) and one deep dive taken to real depth. |
| Staff+ | All of that, plus the idempotency-key lifecycle (minted where, persisted where, spent when) and entitlement-scoped caching, where identity is part of the cache key and a gated tier never reaches the device. |
The depth below is written at senior-to-staff. A mid-level reader should treat the deep dives as reference, not as a script to deliver.