System Design

Ticketing System

Design an event ticketing system like Ticketmaster.

Functional requirements

• Users can browse events and view real-time seat availability (seat maps for reserved seating, quantity counts for general admission).
• Users can select specific seats (or a quantity for GA), which places a temporary hold for a fixed window (e.g., 10 minutes) while they complete checkout.
• Users can complete purchase (payment) to convert a hold into a confirmed ticket; expired or abandoned holds return seats to inventory.
• The system supports scheduled on-sale times where tickets for a popular event become purchasable at an exact moment, with a waiting-room/queue experience for demand exceeding capacity.
• Users can view their purchased tickets and receive a confirmation with a unique, verifiable ticket identifier.

Non-functional requirements

• Strong consistency for inventory: a seat must never be sold to two different buyers, even under extreme concurrency. Correctness of inventory takes priority over availability of the purchase path.
• Browse/read paths (event pages, seat maps) should remain highly available and fast (p99 < 500ms) even during on-sale spikes; slightly stale availability display is acceptable.
• Fairness during on-sales: purchase opportunity should be roughly ordered by arrival, and the system should resist bots and multi-connection gaming.
• Confirmed purchases are durable: once a user is charged and confirmed, the ticket must never be lost or revoked by the system.
• The system must degrade gracefully under 100x normal load at on-sale moments rather than collapsing (no thundering-herd failure of the checkout path).

Scaling & constraints

• 50M registered users; a typical day sees 5M DAU browsing and ~200K ticket purchases across ~10K active events.
• A major on-sale (e.g., stadium tour) offers ~50K to 100K seats per event and attracts 5M to 10M interested users hitting the site within the first minute.
• Read:write ratio during on-sales is roughly 1000:1 (seat-map views and availability polls vs. actual hold/purchase attempts).
• A seat record is ~500 bytes; a ticket/order record is ~2 KB; ticket and order history must be retained for 7 years.
• Hold window is 10 minutes; assume 30 to 50% of holds are abandoned during hot on-sales.
• Traffic grows ~30% year over year; peak on-sale events occur a few times per week, not continuously.

Out of scope

• Payment processing internals (assume a third-party payment gateway with an authorize/capture API).
• Secondary market / resale, ticket transfers, and dynamic pricing.
• Venue seat-map authoring tools and event creation/admin workflows.
• Physical entry validation hardware (barcode scanners at the gate).