Ticketmaster (Seat Booking): System Design

Requirements & API: Ticketmaster (Seat Booking)

What an interviewer expects you to nail down before drawing a single box.

Functional

•Show real-time seat availability for an event and let a user select specific seats.
•Place a short-lived hold on selected seats while the user checks out, auto-releasing on timeout or abandonment.
•Throttle access to hot drops via a virtual queue that admits users at a sustainable rate.
•Confirm the booking only after payment succeeds, then durably mark seats sold and record the order.

Non-functional

•No double-booking under extreme contention. Two users must never both buy seat 42A, even at 10M concurrent requests.
•Survive a sudden load spike. A Taylor Swift drop must degrade into an honest queue, not a wave of 503s.
•Holds must auto-expire (Redis TTL) so abandoned carts don't make a venue 'sell out' at 30% capacity.
•Transactional, durable allocation in Postgres. The lock layer is fast, but the DB is the source of truth that prevents double-sells.

API contract

GET /v1/events/{id}/seats → { seats: [{ id, status, price }] }

Polled by the client to keep the map fresh as others book.

POST /v1/events/{id}/holds { seat_ids, session } → { hold_id, expires_at }

Acquires Redis seat locks with a TTL. Requires a valid queue-passed token.

POST /v1/holds/{id}/checkout { payment, idempotency_key } → { order_id, status }

Confirms only on payment success; commits the seats transactionally in Postgres. The idempotency key makes a retry or double-click return the original order instead of charging twice.

GET /v1/queue/{event_id}/position → { position, eta }

Virtual-queue status while waiting for admission.

About Ticketmaster (Seat Booking)

Think about the moment a Taylor Swift tour goes on sale and ten million people slam the site in the same thirty seconds, all reaching for the same few thousand seats. Two of them must never both walk away with seat 42A, and the site has to stay up. That collision of extreme contention and a wave of traffic is the whole problem.

Here is the whole thing in plain terms. When a hot drop goes live, users do not hit the booking flow directly. A virtual queue puts them in a waiting room and drips them onto the real system at a rate it can actually handle, handing each one a position number and an honest ETA. The API gateway checks for a signed 'queue passed' token so nobody can sneak around the line. Once admitted, a user picks a seat and the booking service grabs a short-lived lock on it in Redis with a SETNX, holds it for about five minutes, calls Stripe for payment, and only on success commits the seat as sold.

The Redis lock has a TTL, and that detail does the heavy lifting. It is like a store clerk holding an item at the counter for five minutes: if you wander off, it goes back on the shelf automatically. Without that auto-expiry, abandoned carts would lock seats forever and a venue would 'sell out' at thirty percent capacity. The TTL has to roughly match real checkout time, since too short loses buyers and too long ties up inventory.

The lock layer is fast but it is not the source of truth. When payment succeeds, the booking service runs a single atomic transaction in Postgres that marks the seat sold and writes the order together. Either both commit or neither does, so you never end up with a charged customer holding no ticket. Redis owns the transient hold, Postgres owns the durable allocation that actually prevents double-sells.

This system teaches the lock-plus-TTL pattern for holding limited inventory, why a virtual queue beats plain rate-limiting on user experience while protecting the backend just as well, atomic transactions for money-adjacent writes, and the split between a fast transient lock layer and a durable transactional source of truth.