Home › Scenarios › Ticket flash sale
System design scenario
Design a ticket flash sale (like Ticketmaster)
Intermediate
Tickets go on sale and traffic spikes 10x in seconds. Most requests try to reserve a seat (writes), all hitting one primary database.
▶ Simulate this designThe goal
Keep p99 < 500 ms and error rate < 1.00% at 300,000 req/s for 10s.
- Peak load
- 300,000 requests per second
- Traffic mix
- 30% reads, 70% writes
- p99 latency
- under 500 ms
- Error rate
- under 1.00%
The starting architecture
The simulator opens with this design. It is deliberately too weak for the goal: run it and watch which component saturates first.
- Load balancer (Load Balancer, 2 instances): Load balancer in front of the booking service.
- Booking service (Service, 100 instances): Booking service: checks availability and reserves seats; autoscales, but slowly.
- Inventory DB (Database): Inventory database. Seat reservations are writes, so they all land on the primary.
How to approach it
The hints unlock one at a time in the app. Try the design yourself before reading them.
Show the hints
- Writes only go to the primary: replicas will not save you here.
- Put a queue between the booking service and the database to absorb the spike.
- Retries during overload make things worse. Watch the retry traffic on the chart.
What the simulator shows you
SimLoad models every component as a queue with real capacity, latency, timeouts and retries, so you see utilisation, p50/p99 latency, errors and monthly cost change as you scale. Insights name the bottleneck in plain language, and the capacity planner sizes the fix. A reference solution that meets the goal is verified by automated tests.
▶ Try it in the simulator