E-Commerce & High-Scale Logistics

Design a High-Concurrency Ticket Reservation & Flash Sale System (Ticketmaster / Queue-IT)

Staff / Principal

Architect an extreme-concurrency ticket reservation engine featuring virtual waiting rooms, distributed seat locking with TTL, optimistic inventory concurrency, and fraud-resistant bot protection.

Production Scale: 10 Million Concurrent Users • 50,000 Seats Sold in 10 Seconds • Zero Double-Booking

Functional Requirements

  • •Users select specific arena seats and place a 10-minute temporary reservation lock
  • •If checkout is completed, the seat is permanently marked SOLD
  • •If checkout expires or is cancelled, the seat lock releases back to the inventory pool immediately
  • •Queue users in a fair FIFO Virtual Waiting Room during peak demand

Non-Functional Requirements

  • •Strict zero double-booking guarantee (Absolute data consistency)
  • •System resilience under 100x traffic spikes
  • •Sub-100ms UI feedback for seat selection

Capacity & Scale Estimation

Concurrent Queue Users10,000,000 users in virtual waiting room
Venue Capacity50,000 seats per stadium event
Peak Seat Selection Requests500,000 requests/sec at sale launch
Hold Lock Duration600 seconds (10-minute checkout timer)

Core Architectural Components

1Virtual Waiting Room (Queue-IT / Cloudflare Waiting Room)

Shields backend by issuing cryptographically signed queue tokens, admitting users in controlled batches of 1,000/sec.

2Seat Inventory Cache (Redis Bitmap & Hashes)

Maintains in-memory real-time seat availability map; atomic `SET NX PX 600000` acquires temporary 10-minute seat locks.

3Distributed Lock Manager (Redis Redlock)

Guarantees exclusive mutual exclusion across multi-node Redis clusters when locking adjoining group seats.

4Transactional Inventory Database (PostgreSQL with Row-Level Locking)

Final source of truth executing `UPDATE seats SET status = 'SOLD' WHERE id = ? AND version = ?` with optimistic locking.

5Lock Expiration Sweeper (Redis Keyspace Notifications)

Listens for expired seat lock events and immediately broadcasts availability updates via WebSockets.

Architectural FAQs & Interview Deep Dives

How do you guarantee that two users clicking the exact same seat at the same millisecond don't both get it?

By executing an atomic Redis `SET seat:{eventId}:{seatId} {userId} NX EX 600`. The `NX` (Not Exists) flag guarantees that only the first request acquires the lock; all subsequent attempts fail with 409 Conflict.

What happens if a user closes their browser without completing payment?

The Redis key has a 600-second (10-minute) TTL. When the key expires, a Redis Keyspace Notification triggers the lock release, returning the seat to the available pool automatically.

Why is a Virtual Waiting Room necessary in front of the API servers?

If 10 million users hit a 50,000-seat database simultaneously, servers would crash from connection pool exhaustion. The waiting room acts as a buffer, admitting only 1,000 users per second to match processing capacity.

How does Optimistic Concurrency Control (OCC) work in the persistent database layer?

Each seat row contains a `version` integer. The SQL commit runs `UPDATE seats SET status='SOLD', version=version+1 WHERE id=? AND version=current_version`. If another process modified it first, 0 rows are updated and the transaction rolls back.

How do you prevent scalper bots from acquiring all tickets instantly?

By integrating proof-of-work CAPTCHAs, device fingerprinting, signed queue tokens with encrypted nonces, and limiting max seats per verified phone/credit card.

How is seat availability updated on thousands of user screens in real-time?

Via server-to-client WebSockets or Server-Sent Events (SSE) broadcasting delta coordinate updates when seats transition between AVAILABLE, RESERVED, and SOLD.