How Would You Design Ticketmaster?
Learn how to design Ticketmaster: seat holds with TTL, virtual waiting rooms, and strong consistency for high-contention inventory.
Expected Interview Answer
Designing Ticketmaster centers on solving high-contention seat inventory: when a popular event goes on sale, thousands of clients race to reserve the same limited seats, so the system needs a short-lived reservation lock per seat, a queue to shed excess concurrent load, and a payment step that only finalizes the sale after the lock is confirmed.
When a user selects seats, the system places a temporary hold (e.g., a row lock or a TTL-based key in a fast store like Redis) on those specific seats for a few minutes, preventing anyone else from selecting them while the buyer completes checkout; if checkout does not complete before the TTL expires, the hold is released automatically. For extremely high-demand on-sales, a virtual waiting room or queue sits in front of the booking flow to admit users in controlled batches, protecting the booking service and database from being overwhelmed by a spike of simultaneous requests. The actual seat state (available/held/sold) must be updated with strong consistency — this is one of the rare cases where a distributed system needs synchronous, serialized writes per seat (row-level locking or a compare-and-swap) rather than eventual consistency, because double-selling a seat is unacceptable. Payment processing is decoupled as its own step: the seat is only marked permanently sold after payment is confirmed, with the hold acting as the reservation in between.
- Short-lived seat holds prevent double-booking without locking the entire event indefinitely
- A waiting-room/queue in front of checkout protects the booking database during flash-sale spikes
- Strong consistency on seat state (vs. eventual) is applied only where it truly matters, keeping the rest of the system scalable
- Decoupling payment confirmation from the hold avoids selling a seat before payment actually succeeds
AI Mentor Explanation
Designing Ticketmaster is like a stadium's seat-booking desk during a sold-out final, where a fan who points at a seat gets a brief, timed hold on it — a physical marker placed on the chair — while they finish paying, so no one else can claim that exact seat in the meantime. If the fan does not complete payment within the allotted minutes, the marker is removed and the seat returns to availability instantly. Because thousands of fans rush the ticket window the moment sales open, the venue funnels people through a single-file queue outside instead of letting everyone crowd the desk at once. That timed hold plus controlled admission queue is exactly how a high-demand booking system prevents double-selling under load.
Step-by-Step Explanation
Step 1
Admit users through a controlled queue
A virtual waiting room throttles how many users reach the booking flow at once during a high-demand on-sale.
Step 2
Place a short-lived seat hold
Selecting seats writes a TTL-based reservation (row lock or fast-store key) that blocks other buyers from selecting the same seats.
Step 3
Confirm payment before finalizing
The seat is only marked permanently sold once payment succeeds; the hold is the reservation bridging selection and payment.
Step 4
Release expired holds automatically
If checkout is not completed before the TTL expires, the hold is released and the seat becomes available again.
What Interviewer Expects
- Identifies seat inventory as the high-contention core problem, not a generic CRUD service
- Proposes a short-lived hold/lock mechanism with a TTL to prevent double-booking
- Mentions a virtual waiting room / queue to shed load during flash on-sales
- Correctly argues strong consistency is required for seat state, unlike most of the rest of the system
Common Mistakes
- Treating every part of the system as eventually consistent, including seat inventory itself
- Forgetting the hold/reservation step and letting payment directly determine seat ownership with no interim lock
- Not addressing the traffic-spike problem of a flash on-sale (assuming steady, evenly distributed load)
- Designing a lock with no expiry, causing seats to be stuck unavailable if a user abandons checkout
Best Answer (HR Friendly)
“The hard part of building something like Ticketmaster is that thousands of people might try to buy the same seat at once, so I would put a short timer-based hold on a seat the moment someone selects it, which blocks everyone else from grabbing it until that timer runs out or the purchase is confirmed. For a massive on-sale, I would also add a virtual waiting room in front of checkout so the booking system does not get overwhelmed by everyone hitting it at the exact same second.”
Code Example
HOLD_TTL_SECONDS = 300 # 5 minutes
def try_hold_seat(seat_id, user_id, cache):
key = f"seat_hold:{seat_id}"
# SET ... NX ensures only one holder can acquire the lock
acquired = cache.set(key, user_id, nx=True, ex=HOLD_TTL_SECONDS)
return bool(acquired)
def confirm_purchase(seat_id, user_id, cache, db):
key = f"seat_hold:{seat_id}"
holder = cache.get(key)
if holder != user_id:
raise Exception("Hold expired or seat held by another user")
if not payment_service.charge(user_id, seat_id):
raise Exception("Payment failed")
db.mark_seat_sold(seat_id, user_id) # strongly consistent write
cache.delete(key)Follow-up Questions
- How would you implement the virtual waiting room so it fairly and efficiently admits users?
- What happens if two requests race to hold the same seat at the exact same millisecond?
- How would you scale seat-hold storage across an event with hundreds of thousands of seats?
- How would you handle a payment that succeeds after the hold has already expired?
MCQ Practice
1. Why does a ticketing system need a short-lived hold on a seat before payment completes?
A TTL-based hold blocks concurrent buyers from claiming the same seat during checkout, then auto-releases if the buyer abandons the purchase.
2. Why is seat inventory a case where strong consistency is required, unlike much of a large-scale system?
Unlike metrics or counters, seat state must never allow two confirmed sales for one seat, so writes need to be serialized/strongly consistent.
3. What is the primary purpose of a virtual waiting room in front of a high-demand ticket sale?
A waiting room protects backend capacity by controlling the rate at which users are let into the actual booking/checkout flow.
Flash Cards
Why does seat selection need a TTL-based hold? — To block other buyers from claiming the same seat while the current buyer completes checkout, auto-releasing on timeout.
What protects the booking system during a flash on-sale? — A virtual waiting room/queue that admits users in controlled batches instead of all at once.
Why is seat state strongly consistent while most of the system is not? — Because double-selling a physical seat is unacceptable, unlike slightly stale data elsewhere in the system.
When is a seat marked permanently sold? — Only after payment is confirmed; the hold is the temporary bridge between selection and payment.