Design a Ticket Booking System (Flash Sale)

Commerce, Payments & LedgersHarddesign-ticket-booking

Design a Ticket Booking System (Flash Sale)

Design for the worst traffic shape there is: a million people hitting one endpoint at 10:00:00 for fifty thousand seats, each of which may be sold exactly once.

Virtual Waiting RoomDistributed LocksQueue-Based Load LevellingSeat Maps

Traffic & Capacity Estimates:

1M concurrent users at on-sale · 50k seats · 100x normal traffic for 5 minutes

Functional Requirements

•Admit users into the sale through a fair virtual waiting room with a visible position.
•Render a live seat map and hold specific seats during checkout with a short TTL.
•Confirm purchase atomically and release unsold holds immediately on expiry.
•Detect and block bots and scalpers without blocking legitimate buyers.

Non-Functional Requirements

•No seat is ever sold twice, regardless of concurrency.
•The system must shed load predictably rather than collapse — a queue position beats a 503.
•Waiting-room ordering must be fair and demonstrably so.

Back-of-the-Envelope Math

1M users arriving in 10 seconds = 100k requests/second against an inventory of 50k rows.
Admitting 500 users/second into checkout keeps the inventory tier at a load it can actually serve.

Key Architectural Trade-offs

A waiting room converts an unservable spike into a throttled stream; it is a product compromise (users wait) chosen deliberately over an outage.
Per-seat locks in Redis are fast and need a fencing token to be safe under failover; a database row lock is safe and becomes the bottleneck at 100k RPS.
Optimistic 'first write wins' is simplest and produces a bad experience for the 95% who lose the race — hence holds, queues, and explicit position feedback.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow