Design Ticketmaster: Event Booking That Survives On-Sale Spikes

Users search for events by name, performer, city or date. They open an event and see its seat map with current availability, so they can tell which sections still have room. Finally, they book: pick seats, have those seats reserved briefly while they enter payment details, pay, and receive confirmed tickets.

Splitting booking into hold, pay and confirm is a deliberate product choice. Without a temporary hold, a fan could spend two minutes typing card details only to discover the seat was taken mid-checkout. Secondary resale, demand-based pricing and organiser dashboards are left out because each brings its own workflows that would distract from the core booking problem.

The requirements here differ by area, and saying that explicitly is a strong interview signal. Booking requires strong consistency: every seat sells to exactly one buyer. The platform must survive on-sale spikes in which millions of users hit a single event within a minute.

Fairness matters too. Fans should be admitted roughly in the order they arrived, and automated scripts should not grab the best seats ahead of humans. Browsing, by contrast, prioritises speed and availability. Search results and seat maps must load quickly and stay up, and it is acceptable for a seat map to lag reality by a second, because the booking step performs the authoritative check anyway.

On an ordinary day, assume roughly 20 million daily active users who mostly search and browse. If they run around 200 million searches per day, that works out to about 2.3K searches per second, a load any well-built search cluster handles comfortably.

Now consider one popular event: a stadium concert with about 50 thousand seats. At the on-sale moment, assume 5 million fans arrive together, which is roughly 100 people competing for each seat, all within a few seconds. That burst is orders of magnitude above the daily baseline and concentrated on a single event's data. The estimate tells us where to spend effort: the everyday load is routine, and the architecture must be shaped around that on-sale spike.

Four entities model the domain: the event, the venue, the ticket representing one seat at one event, and the booking that groups the tickets a user is buying. Treating each seat-event pair as its own ticket row gives us a natural unit to hold, lock and mark as sold.

Search uses GET /events/search with query, city and date filters. Opening an event uses GET /events/{id}, returning the event, its venue and the seat map. Booking is two calls. POST /bookings/hold takes the event and the chosen seat_ids, places a temporary hold, and returns a booking_id with an expires_at timestamp. POST /bookings/{id}/confirm sends a payment_token; when the charge succeeds, the seats are marked sold and tickets are returned. Splitting the flow keeps payment out of the hold step, so holds stay fast.

All traffic enters through an API gateway that authenticates users, applies rate limits and routes requests. Searches and event pages go to an event service backed by an Elasticsearch index, and event pages are cached aggressively because thousands of people view the same few pages.

Booking requests for a high-demand event first pass through a virtual waiting room that admits users to the booking flow in controlled batches. Once admitted, the booking service places seat holds in Redis with a ten-minute expiry, so seats left in abandoned carts free themselves without any cleanup job. On confirmation, the booking service charges the user through a payment provider such as Stripe and then marks the seats as sold in a Postgres tickets database, which is the system of record.

Changes to events and seat status are streamed into the search index via change data capture. Keeping the event service and the booking service apart ensures that heavy browsing never competes for resources with people in the middle of paying.

One option is pessimistic locking: take SELECT ... FOR UPDATE on the ticket rows and hold that lock until payment completes. That is correct, but holding row locks for minutes during an on-sale would exhaust connections and stall the database. A second option records a reserved status and expiry directly on the ticket row. That keeps one source of truth, yet every hold becomes a database write, and a background job must sweep expired holds back to available.

The chosen option places holds in Redis. A small atomic script runs SET seat:{id} {user} NX EX 600 for each requested seat, succeeding only if no other user already holds it. The first writer wins, and if the buyer walks away the keys simply expire after ten minutes. Redis handles this at very high throughput, which is exactly what the on-sale needs.

Redis is a fast gatekeeper, not the final authority. At confirmation, the booking service runs a conditional update in Postgres that changes status to sold only where the seat is still available. Even if a Redis node failed and a hold vanished, that check prevents a second sale. The payment request also carries an idempotency key, so a retried confirmation cannot charge the card twice.

The waiting room is enabled ahead of time for events expected to sell out, while ordinary events bypass it. Each arriving user is added to a Redis sorted set scored by arrival time, which preserves fairness and lets the system compute anyone's position quickly.

Users watch their place in line update over a WebSocket. A concrete message such as being number 40,000 in the queue is surprisingly important: it stops people from hammering refresh, which would otherwise multiply the load. Behind the scenes, an admission service releases batches of users at a pace the booking service can sustain, and slows down as inventory runs low so people are not admitted to an empty venue.

Each admitted user receives a short-lived, signed access token. The booking APIs reject any request without a valid token, so a script cannot jump the queue by calling the hold endpoint directly. Combined with per-account and per-device rate limits, this turns an uncontrolled stampede into a steady, predictable stream of buyers.

Event discovery runs on Elasticsearch, indexing name, performer, venue, city and date, which supports typo-tolerant queries alongside filters. The index is kept current through change data capture, with Postgres changes flowing through Kafka into the index within seconds, so the booking service never writes to two stores.

Before a big release, huge numbers of fans load the identical event page and seat map, so popular searches and pages are cached in Redis and at the CDN. The seat map itself is split in two: the venue layout, which almost never changes, is served as a static asset from the CDN, while only a compact list of seat statuses is fetched live. That keeps the dynamic payload small even for a 50,000-seat stadium. Finally, browsing and booking run as separate services, so a surge in searching cannot slow down a buyer who is in the middle of paying.

Holding seats in Redis instead of the database gives speed and automatic expiry, with the cost of a second check in Postgres at confirmation. The waiting room protects the backend and feels fair, but users accept a delay instead of booking instantly. Applying strong consistency only to booking, while letting search and seat maps lag by a few seconds, keeps most of the system cheap and highly available.

Hold duration needs tuning. A window that is too short causes users to lose seats while still entering card details; one that is too long leaves seats locked by people who have wandered off while others wait in line. The overall pattern is worth memorising for any flash-demand system: be strict where money and ownership change hands, relax consistency for browsing, and put a queue in front of the spike.