Loading…

Design a Ticket Booking System (Ticketmaster) — SystemRound

Design a Ticket Booking System (Ticketmaster)

hardSystem design45 min5 stages

Asked atAmazonGoogleUberStripeBookMyShowTicketmaster

Design a ticket booking system like Ticketmaster or BookMyShow for live events (concerts, sports). Users browse events, select seats from a venue map, and complete payment — all while thousands of other users compete for the same seats. The system must prevent double-booking (two users paying for the same seat), handle massive traffic surges when popular events go on sale, and provide a fair booking experience under extreme contention.

Best after a few full reps. Expect follow-up questions, edge cases, and deeper trade-off discussion.

What this problem tests

Core APIsTwo-Phase BookingAPI QualityCore ComponentsDouble-Booking PreventionSurge Handling

Round shape

5 stages

Time budget

45 min

Feedback loop

Grade anytime

Guided practice·Primary loop

Guided practice

Workspace-first, hints visible, stage retry available. The cheap, repeatable loop — build the answer shape before you take it under pressure.

Stage-by-stage workspace instead of a blank page.
Grade one stage or the whole answer whenever you want.
Compare your answer against reference checkpoints and model answers.

Solve once, compare against the checklist, then come back to the weak stage instead of starting over.

Mock interview·Pressure test

Mock interview

Strict timer, hints hidden, debrief deferred to the end. Use this once you can already structure a clean answer and want to pressure-test pacing and pushback.

Best once the answer shape is already in your head.
Pressure-test pacing, pushback handling, and communication.
Use diagnosis after the interview for exact misses and next study steps.

Best after one structured rep · timed · focused on pacing and communication.

Requirements

This is the framing pass. A strong answer quickly defines what the system must do, what quality bar it has to hit, and the numbers that will justify the rest of the design.

First 5 min of the round

What must exist

Functional Requirements

6 items

1Browse events and view seat availability on a venue map

2Select 1-6 seats and enter checkout

3Seats temporarily held (10 min TTL) while payment processes

4Confirmed booking after successful payment — seat moves to "booked"

5No double-booking — a seat is sold to exactly one user

6Below the line: waitlist, dynamic pricing, refunds

What good looks like

Non-Functional Requirements

5 items

1Strong consistency for seat state transitions (available → held → booked)

2Surge handling: 10K+ users competing for the same 100 seats when a popular event drops

3Graceful degradation: virtual waiting room / queue during surge, not 500 errors

4Payment idempotency: charge the user exactly once, even with retries

5Durability: a confirmed booking with a charged payment must never be lost

Numbers to anchor the design

Scale Estimation

5 items

150M events/year, avg 5K seats per event → 250B seat-states to manage

2Popular event surge: 10K-100K users in the first 60 seconds

3Booking QPS: ~16/sec average, but 10K/sec during a surge (500× spike)

4Seat map reads: 100× more than writes (users browse before buying)

5Hold expiry: ~30% of holds expire without payment → seats released back

How the round unfolds

Each stage has a distinct job. Treat them like separate deliverables instead of one giant answer, and the round becomes much easier to navigate.

4 design stages · 40 pts after framing

🔌

Stage 2~5 min10 pts

API Design

Define the contract clearly: the endpoints, auth boundary, error semantics, and the one or two decisions that matter most.

What you should produce

Define the API for the booking flow.

Strong answers cover

Core APIsTwo-Phase BookingAPI Quality

🏗️

Stage 3~10 min10 pts

High-Level Architecture

Lay out the main components and trace the write path, read path, and any async path cleanly.

What you should walk through

Walk me through the architecture.

Strong answers cover

Core ComponentsDouble-Booking PreventionSurge Handling

💾

Stage 4~10 min10 pts

Data Model & Storage

Pick the store, show the schema or key model, and explain why that storage choice fits the access pattern.

What you should lock in

Let's go deeper into the data model.

Strong answers cover

Schema DesignState MachineStorage Choice

📈

Stage 5~15 min10 pts

Scaling & Deep Dive

Name the first bottleneck, failure modes, and the trade-offs that keep the system fast and reliable under pressure.

What you should pressure-test

Let's talk about the hard parts: the surge when Taylor Swift tickets go on sale, payment failure recovery, and the hold expiry mechanism.

Strong answers cover

Surge / Hot Event HandlingPayment Failure RecoveryDeep Dive Quality

What a strong first rep looks like

Scope clearly

Translate the prompt into concrete requirements, scale, and trade-offs before drawing architecture.

Stay stage-specific

Give APIs in the API stage, data models in the storage stage, and failure modes in scaling. Don't blur them together.

Iterate fast

Grade early, compare to the reference checkpoints, fix the biggest misses, and re-submit the weak stage instead of starting over.