Seats Are Selling
Design the seat reservation system for a Ticketmaster style flash sale: one stadium show, 50,000 seats, and roughly 2 million people hitting the sale the second it opens.
Requirements
Functional:
- Browse a live seat map and see which seats are already taken.
- Pick specific seats or ask for best available, then receive an exclusive hold.
- Pay inside the hold window and get a confirmed ticket.
- Release the seats automatically when the user does not pay in time.
Non-functional:
- No double booking. A seat is sold at most once, including during a failover.
- An admitted user gets a hold decision in under 300 ms at p99.
- The sale stays fair and legible to the 2 million people who are waiting.
- Payment runs through a third party processor that can take 30 seconds and can fail.
Scale
- 2,000,000 users arrive over about 5 minutes, roughly 60% of them inside the first 60 seconds.
- Peak edge arrivals near 20,000 per second. Unthrottled, that is 60,000 to 100,000 API req/s.
- 50,000 seats with an 8 minute hold window, so useful hold throughput is in the hundreds per second, not the tens of thousands.
- Seat map payload is about 2 MB raw for 50,000 seats, near 300 KB compressed.
- Hold, order, and audit data for one event stays under 1 GB, so storage is not the constraint.
- Targets: p99 hold latency 300 ms, seat map staleness budget 2 seconds.
Out of scope
Ticket transfer and resale, dynamic pricing, fraud scoring, the mobile client itself, and the venue box office integration.
Sign in to answer questions and track your progress
Sign In