Loading…

Understanding the problem

Ticketmaster sells tickets to live events: a fan opens an event, looks at the seat map, picks seats, pays and gets tickets. The hard part is that every seat is unique and finite, and for a popular show a crowd many times bigger than the venue arrives at once. So the design is about three things: each seat goes to at most one fan, money and tickets agree, and the system stays up and fair in the first minute of a big sale.

The practice brief states the requirements up front; in an interview you would confirm them in the first few minutes. The core is the booking path: browse, hold, pay, confirm.

Functional requirements

CoreBrowse an event’s seat map and see which seats are available.
CorePick up to 6 reserved seats and keep them while you pay: buyers have about 10 minutes to finish checkout once they have picked their seats.
CorePay through an external Stripe-like payment provider.
CoreReceive a confirmed booking with tickets once the payment succeeds.
Below the lineLook up where an order stands (for example after a dropped connection).
Below the lineEmail the tickets to the buyer.
Below the lineSee past bookings.
Below the lineDelivering tickets and scanning them at the gate.A separate system that starts once a booking is confirmed.
Below the lineWaitlists when a show sells out.It reuses the hold and admission machinery. Mention it and move on.

Non-functional requirements

ConsistencyEach seat goes to at most one buyer. What a buyer ends up with must be exact.
ConsistencyA charged payment always ends in a confirmed booking or an automatic refund.
LatencyThe seat map may be a few seconds stale.
AvailabilityStay up and responsive during the on-sale spike: the seat map loads in about a second.
DurabilityConfirmed bookings are durable: never lost once confirmed.
Below the lineActive-active writes across regions.One primary region with a standby is enough, and multi-region writes add conflicts the design doesn’t need.
Below the line

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 50M monthly users; normally a few dozen bookings per second.
ScaleA popular on-sale: about 100,000 people arrive in the first minute, for one event with a few tens of thousands of seats.
ScaleVenues from 500-seat theatres to 80,000-seat stadiums; every seat is reserved (assigned).
ScaleUp to 6 seats per order; groups usually want seats together.

Out of scope

Out of scopeRunning several huge on-sales at the same moment.
Out of scopeCreating events and managing venues.
Out of scopeSearch and recommendations.
Out of scopeBuyer-requested refunds, resale and dynamic pricing.
Out of scopeThe payment provider’s internals.

Check yourself

Search is out of scope here. Why is it safe to leave it out of the booking design?
Show answerHide answer
Search is a read-heavy system over event data that may be stale. It doesn’t touch seat ownership or money, so it doesn’t change how the booking path works.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Work out only the few numbers this design depends on, with round figures and one line of working each. The point is to find which number is the problem, and by roughly how much.

Back of the envelope for one stadium on-sale

Quantity	Value	Working
Arrivals	About 1,700 a second	100,000 fans in the first minute ÷ 60: roughly a hundred times a normal day, all on one event.
Seat-map reads	30,000 to 50,000 a second	100,000 fans refreshing every two or three seconds.
Claim attempts	Several hundred to a thousand a second	A third of arrivals trying to hold seats in the first minute.
Seat database	A few hundred concurrent writes	The figure this problem gives.
Inventory rows	Under 100,000 per event	One row per seat; the largest venue has 80,000.

What the numbers tell you

Reads outnumber claims by one or two orders of magnitude, so serve the seat map away from the database.
Claims outnumber what the database can take, and fans outnumber seats, so something must control how many buyers reach it.
The data is small. The problem is contention on a few hot rows, not storage.

Architecture diagramWhere the first minute lands

Try it: The numbers that shape the designGuided practice · Ticket booking, Stadium on-sale · Senior

Check yourself

Which of these numbers breaks a naive design, and by how much?
Show answerHide answer
Claims against database capacity: several hundred to a thousand attempts a second against a few hundred concurrent writes, with far more fans than seats. The reads are bigger, but a cache absorbs them.

Core entities

Keep the model small and put the rules where the data lives. The row that matters is one seat for one event: every buyer contends on it, and it is where "at most one buyer" is enforced. Keep inventory in Postgres: the booking path needs transactions, conditional writes, constraints and durable commits, and the data is small. A cache-only store can lose holds or bookings on failover.

The entities and their key fields

Entity	Key fields	Why it exists
Event	`id`, `venue_id`, `starts_at`, `on_sale_at`	What is on sale, and when.
Venue seat	`venue_id`, `seat_id`, section, row, number	The seating plan, shared by every event there.
Event seat	`event_id`, `seat_id`, `status`, `hold_id`, `held_until`, price	The inventory everyone contends on.
Hold	`id`, `event_id`, `buyer_id`, `expires_at`	A buyer’s claim while they pay.
Order	`id`, `hold_id`, `buyer_id`, amount, `status`	The purchase; its id is the idempotency key.
Ticket	`order_id`, `seat_id`, code	Issued when the order is confirmed.

The life of a seat

From	To	What causes it	Allowed
available	held	One buyer’s claim	Yes
held	available	The deadline passes, the buyer backs out, or payment fails	Yes
held	booked	Confirm against this buyer’s live hold	Yes
available	booked	A purchase without a hold	No: every sale goes through a hold
held by A	held by B	A second claim on a live hold	No: only after it lapses
booked	held or available	Anything in the booking path	No: only a refund flow (out of scope)

Read:Learn: Data model design Learn: Storage choice justification

Try it: Core entities and the life of a seatGuided practice · Ticket booking, Stadium on-sale · Senior

Check yourself

Why not keep seat status only in Redis?
Show answerHide answer
Redis is fast, but on failover it can lose recent writes, and the brief needs sold seats to stay sold. Keep the record in a database with durable commits and constraints; a Redis layer can sit in front for speed.

The API

Keep holding and buying as separate calls: that keeps a fan’s seats safe while they type their card number. Every write is safe to repeat: a hold carries an idempotency key, and confirm is keyed by the order id. One order resource moving through held, paid and confirmed works equally well.

From seat selection to a confirmed ticket

Call	Request	Response	Errors
`GET /events/{id}/seats`	None	The seat map, from a cache that may be seconds old	None
`POST /events/{id}/holds`	`seat_ids` (up to six), an idempotency key	`201` with `hold_id` and `hold_deadline`	`409` with `unavailable_seat_ids`; `403` without an admission token
`DELETE /holds/{id}`	None	`204`: the seats are back on sale	`404` if the hold already ended
`POST /orders`	`hold_id`	`201` with `order_id`, the amount and what the app needs to pay	`409` if the hold is no longer valid
`POST /orders/{id}/confirm`	None: the order id is the key	`200` with the booking and tickets	`409` seats lost, refund started; `402` payment failed
`GET /orders/{id}`	None	`pending_payment`, `confirmed`, `refunding` or `refunded`	None

Read:Learn: API contract design Learn: Idempotency and retries

Try it: From seat selection to a confirmed ticketGuided practice · Ticket booking, Stadium on-sale · Senior

Check yourself

Why return the unavailable seat ids with a 409, instead of a plain error?
Show answerHide answer
So the app can show which seats went and offer the rest or nearby seats straight away, without another round trip.

High-level design

Build the design one requirement at a time. Each step adds only what that requirement needs; the deep dives then harden the parts an interviewer pushes on.

Browse and load the seat map

The seat map is the hottest read and may be a little stale, so it stays off the primary. The CDN and a short-lived cache answer most requests, and a read replica rebuilds the map on a miss.

The app calls GET /events/{id}/seats.
The CDN answers if its copy is fresh enough; the brief allows a few seconds of staleness.
On a miss, the event service reads the seat-map cache, or rebuilds it from a read replica.
The app draws the map, which shows seats but doesn’t decide who gets one.

Architecture diagramBrowse and load the seat map

The CDN and a short-lived cache answer most reads; a replica rebuilds the map on a miss, leaving the primary for claims.

Diagram as text

Components: Fan's app (Client); CDN (CDN); API gateway (API gateway); Event service (Service); Seat-map cache (Cache); Read replica (SQL DB); Inventory DB (primary) (SQL DB). Connections: Fan's app → CDN (GET seat map); CDN → API gateway (on a miss); API gateway → Event service; Event service → Seat-map cache (fresh copy?); Event service → Read replica (rebuild on a miss); Inventory DB (primary) → Read replica (replication), asynchronous.

Read:Learn: Caching strategy Learn: Read-heavy

Try it: The seat map during an on-saleGuided practice · Ticket booking, Stadium on-sale · Senior

Check yourself

The map is a few seconds stale. Why is that safe?
Show answerHide answer
The claim doesn’t trust it: a hold goes to the source of truth, so a stale map costs a fan a retry, not a double sale.

Hold the seats

The booking service claims the seats at the source of truth, all or nothing, and records the hold with its buyer and deadline. How that stays correct under contention is the first deep dive.

The app calls POST /events/{id}/holds with the seat ids.
One conditional update takes every requested seat only if each is still available, and stamps the hold id and deadline on the rows.
If fewer rows changed than seats were asked for, it rolls back and returns 409 with the seats that went.
Otherwise it returns 201 with the hold id and deadline, and the app shows a countdown.

Architecture diagramHold the seats

Pay and confirm

The order is written before any money moves, and the card goes straight to the provider. Confirm re-checks the hold in the same step that books the seats.

POST /orders with the hold id writes a pending order and creates a payment with the provider, keyed by the order id.
The app sends the card details to the provider, which charges the card.
The app calls confirm, and the provider sends a webhook. Both run the same confirm.
In one transaction, confirm books the seats only if they are still held under this hold, it is this buyer’s, its deadline hasn’t passed by the database clock, and every seat converts.
Otherwise the order moves to refunding, and the fan is told the seats went and the money is coming back.

Architecture diagramPay and confirm

Design Ticketmaster

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

The API

High-level design

Browse and load the seat map

Hold the seats

Pay and confirm

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

04The API

05High-level design

Browse and load the seat map

Hold the seats

Pay and confirm

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this