Design Ticketmaster & Flash-Sale Reservation

System Design Interview•~30 min read•hard

Design a high-concurrency event ticketing platform like Ticketmaster or BookMyShow. The system must handle sudden 1,000,000-user traffic surges attempting to purchase 50,000 seats at the exact same second. It must guarantee strict transactional consistency (zero double-booking), handle user cart abandonment, and prevent database deadlocks.

1. Understand Requirements & Scope

Flash-sale checkout engine handling 50,000 concurrent purchase transactions for 500 limited sneaker SKUs. Failure cascade dynamic: Burst → Pool Saturated → Queue Bloat (10k) → STW GC → 💥 504 Timeouts.

Functional Requirements:

Zero double-booking: A specific seat can never be purchased by more than one user.
Reservation hold: When a user selects a seat, it is locked for 5 minutes to complete payment.
Abandoned inventory release: If payment fails or the user leaves, the seat automatically becomes available again.
High throughput: Protect origin relational databases from thundering herd saturation.

2. Back-of-the-Envelope Capacity Estimation

• Scale: 1,000,000 concurrent users competing for 50,000 tickets.

• Latency: Search and seat map browsing < 100 ms; reservation hold < 500 ms.

• Consistency: Strict ACID compliance on ticket inventory reservation.

3. High-Level Architecture Flow

Ticketmaster burst booking architecture resolves thundering herds via a distributed Virtual Waiting Room (token-bucket rate limiting ingress to 2,000 req/sec), pessimistic row-level locking (SELECT FOR UPDATE) to prevent double-booking, and delayed message queues to release abandoned reservations after 5 minutes.

[ 1 Million Concurrent Fans ]
              |
              v
[ Virtual Waiting Room (Cloudflare Waiting Room / Envoy Queue) ]
              | (Controlled admission: 2,000 req/sec)
              v
[ Booking Service ]
              |
      +-------+-------+
      |               |
      v               v
[ PostgreSQL ]   [ AWS SQS Delay Queue (5-min TTL) ]
(SELECT FOR           |
 UPDATE row lock)     v (If payment fails/abandoned)
                 [ Seat Reversion Worker ] -> Marks seat 'AVAILABLE'

Fig 1. Architecture data flow and component topology.

4. Production Implementation & Code

-- PostgreSQL Atomic Reservation with Pessimistic Row Locking
BEGIN TRANSACTION;

SELECT seat_id, status 
FROM seats 
WHERE event_id = 101 AND seat_number = 'A-42' AND status = 'AVAILABLE'
FOR UPDATE; -- Acquires exclusive row-level lock

UPDATE seats 
SET status = 'RESERVED', 
    reserved_by = 9942, 
    reservation_expires_at = NOW() + INTERVAL '5 minutes'
WHERE seat_id = 42;

COMMIT;

Hardened Implementation Sequence

Virtual Waiting Room: Incoming users are queued in a distributed token bucket system. A rate limiter admits a controlled stream (e.g. 2,000 users/sec) to the seat selection service.
Live Map Browsing: Read seat availability from an edge Redis cache; WebSocket connections push real-time seat lock updates to all active viewing clients.
Pessimistic Row Lock: When user taps "Reserve", execute a transaction in PostgreSQL using row-level locking (SELECT FOR UPDATE) to transition seat status from AVAILABLE to LOCKED with a 5-minute lease.
Delayed Message Queue: Schedule a message in AWS SQS with a 5-minute delay. If payment confirmation has not arrived when the delayed message is consumed, revert seat status to AVAILABLE.

5. Key Decisions & Operational Mitigations

Architectural Decisions & Trade-Offs

•Ingress Admission: Naive unconstrained buffering causes queue bloat and GC exhaustion. Mitigation: Bounded ingress gate with fast non-blocking shedding.
•Resource Strategy: Static capacity allocations collapse under brownouts. Mitigation: Dynamic adaptive limits scaling to real-time physical bounds.
•Outage Impact: Cascading lock convoys and memory saturation. Mitigation: Isolated failure domains keep P99 latency flat and protected.

Operational Hazards & Mitigations

•Cascading Failure: Executing 'SELECT stock FROM inventory WHERE item_id = 101 FOR UPDATE'. 50,000 database transactions serialize behind a single InnoDB/PostgreSQL row lock. HikariCP connection pool (100 connections) exhausts in 12ms; database CPU hits 100% on deadlock detection, crashing the API.
•Breakdown Chain: Burst → Pool Saturated → Queue Bloat (10k) → STW GC → 💥 504 Timeouts
•Shedding Failure: Without fast rejection at the boundary, queued dead work triggers multi-second GC pauses, CPU thrashing, and cascading 504 Gateway Timeouts.

Interactive Knowledge Check • Question 1 of 3↓

Interactive Practice Quiz•Question 1 of 3

advanced

B+ Tree vs LSM-Tree Storage Engine Trade-Offs

Why do high-throughput write-heavy storage engines (like RocksDB and Cassandra) use LSM-Trees instead of traditional B+ Trees?