Ticketmaster

Event Booking

Design a ticketing service where millions of people try to buy a few thousand reserved seats the moment a sale opens, and no seat is ever sold twice.

Overview

A ticketing service sells reserved seats: each seat for a show exists once and can be sold once. Most of the year the load is modest. Then a popular tour goes on sale, and millions of people arrive in the same minute for a few tens of thousands of seats.

Two problems hide in that picture. The first is contention: many buyers want the same few seats, so two of them must never both succeed. The second is the spike: letting everyone hit the booking system at once would take it down, so the crowd has to wait somewhere cheap and be let in at a pace the system can serve. Ticketmaster's own account of the 2022 Taylor Swift on-sale shows both: 3.5 billion system requests in a day, four times its previous peak, and queues slowed down on purpose to keep the site up.

Questions to ask first

Reserved seats or general admission? — Reserved seats; general admission is a counter, which is easier
How big is the largest show? — A 60,000-seat stadium
How many people for one on-sale? — About 2 million waiting when the sale opens
How long can a buyer keep seats while paying? — 10 minutes, then the seats go back on sale
Must the seat map be exact? — No: it may be a second or two stale, but the hold itself is exact
Per-buyer limits and bot checks? — Yes: a ticket limit per account, and bot checks before the queue

What you will be able to do

Explain why the waiting room exists and size it with numbers.
Hold seats so that two buyers can never both get the same seat, and release them when a buyer walks away.
Write the hold, best-available and confirm steps in SQL that is safe under concurrency.
Handle a payment that finishes after the hold expired, and retries of the same checkout.
Say what keeps bots out and what the seat map may and may not get wrong.

Key concepts

Virtual waiting room
Seat holds with expiry
Conditional update
SELECT FOR UPDATE SKIP LOCKED
Idempotent checkout
Seat-map caching
Admission control
Bot defense
Shard by event

Functional requirements

View an event and its seat map with current availability
Join a waiting room before a busy sale and be admitted in turn
Hold one or more chosen seats, or the best available, for 10 minutes
Pay for held seats and receive tickets
Release seats when the hold expires or the buyer cancels
Enforce a ticket limit per account per event

Non-functional requirements

Never sell a seat twice (strict correctness on holds and sales)
Stay up during a spike of millions of arrivals; slow the queue rather than fail
Hold and checkout requests answer in under 500 ms at p99 (a target we chose)
The seat map may lag by a second or two; the hold decision may not
Fair order for people who arrived before the sale opened

Interview questions

How do you guarantee a seat is never sold twice?
Why not just use Redis SETNX with a TTL for holds?
How does the waiting room work, and how many people can it hold?
How does best available work when thousands ask at once?
What happens if payment finishes after the hold expired?
How do you keep the seat map fresh without melting the database?
How do you stop bots?
How do you shard, and what about one huge event?