Design Ticketmaster: Handling the Taylor Swift Problem

14 Million Users, 70,000 Seats, Zero Overselling

When Taylor Swift's Eras Tour tickets went on sale in November 2022, Ticketmaster received 14 million concurrent visitors - more traffic than their system could handle. The site crashed, fans waited hours, and some seats were sold to multiple people. The engineering failure was so severe it triggered a US Senate hearing. The core problem: how do you let millions of users compete for a fixed inventory without overselling, crashing, or creating an unfair experience?

Seat Reservation with Optimistic Locking

Atomic Seat Reservation (prevents double-selling):

  -- Each seat has a version number
  SELECT status, version FROM seats
  WHERE event_id = 'eras-tour-nyc' AND seat = 'A10'
  -- Result: status='available', version=5

  -- Attempt reservation with version check
  UPDATE seats
  SET status = 'held',
      holder_id = 'user_alice',
      held_until = NOW() + INTERVAL '10 minutes',
      version = 6
  WHERE event_id = 'eras-tour-nyc'
    AND seat = 'A10'
    AND version = 5
    AND status = 'available'

  -- Check rows_affected:
  1 row  -> Alice got the seat! Start checkout timer.
  0 rows -> Someone else got it first. Show 'unavailable'.

  Why this works:
  Two users try simultaneously:
  Alice: UPDATE ... WHERE version = 5  -> 1 row (wins)
  Bob:   UPDATE ... WHERE version = 5  -> 0 rows (loses)
  Only ONE UPDATE can match version=5 (atomic operation)

Virtual Queue System

Handling 14M Concurrent Users:

  Without queue: 14M users hit 'Buy' simultaneously
  -> Database melts at 14M concurrent transactions
  -> Site crashes (this is what happened to Ticketmaster)

  With virtual queue:
  [14M users] -> [Queue Service]
                  |
  Assign position: 'You are #847,203 in queue'
  Estimated wait: 45 minutes
                  |
  Release users in batches:
  Batch 1: users #1-1,000 enter purchase flow
  Batch 2: users #1,001-2,000 (after 30 seconds)
  ...
                  |
  Purchase flow:
  1. User selects seats (seat map served from Redis)
  2. Hold seats for 10 minutes (optimistic lock)
  3. Complete payment within 10 minutes
  4. If timeout: release hold, seats return to pool

  Result: database sees 1,000 concurrent transactions
  (not 14,000,000)

Interview Tip

When designing a ticket booking system, cover three things: (1) optimistic locking with version numbers to prevent double-selling (UPDATE WHERE version=N is atomic), (2) virtual queue to smooth traffic spikes (14M users become 1K concurrent purchasers), (3) seat hold timers with background reaper jobs to release expired holds. The key insight: read operations (viewing seat map) are cached aggressively in Redis/CDN, while write operations (reservations) are the only thing hitting the database.

<

/blockquote>

Key Takeaway

Prevent double-selling with optimistic locking or SELECT FOR UPDATE on seat rows. Use a virtual queue to smooth traffic spikes. Hold seats with a timer to prevent permanent blocking. Cache all read-heavy content aggressively - only purchases touch the database.