Home / Blog / System Design Ticket Booking: Interview Talk Track

System Design Ticket Booking: Interview Talk Track

Published 2026-10-16 · Luna Interview

"Design a ticket booking system" (movies, events, airlines) is popular because it forces you to talk about inventory, concurrency, and payments without building an entire marketplace. Candidates often oversell the UI and underspecify seat holds. This system design ticket booking interview talk track keeps the conversation on the hard parts for about 45 minutes.

Ask early whether the interviewer cares more about seat selection, payment flow, or large-scale flash sales.

1. Clarify requirements (5 minutes)

Scope aloud:

"I'll focus on searching events, selecting seats, holding them briefly, completing payment, and confirming a booking—without building the full recommendation or social layer."

Functional

• Browse events / showtimes
• View seat map and availability
• Hold seats for a limited time
• Pay and confirm booking
• Cancel / refund (at least outline)

Non-functional

• No double-booking the same seat
• Fair-enough behavior under spikes (onsale)
• Low latency for seat map reads
• Strong consistency on inventory mutations

Ask: "Single venue or multi-venue? Do we need price tiers and dynamic pricing in v1?"

2. Back-of-envelope (3 minutes)

"Assume 10,000 events, peak 5,000 seat-map reads per second before a popular onsale, and a few hundred booking attempts per second. Inventory writes are fewer than reads but must be correct."

Call out the hotspot: a few events dominate traffic.

3. High-level architecture (8 minutes)

Components:

1. API gateway — auth, rate limits
2. Catalog service — events, showtimes, metadata
3. Inventory / seating service — seat maps, holds, commits
4. Booking service — booking records, state machine
5. Payment service — charge, webhooks, idempotency keys
6. Notification service — email/SMS confirmation
7. Datastores — relational DB for bookings; carefully designed store for seats

Flow: select seats → create hold → pay → confirm booking → release hold on timeout/failure.

4. Seat inventory deep dive (12 minutes)

This is usually the heart of the interview.

Seat states

Hold pattern

1. User selects seats
2. Service attempts an atomic transition AVAILABLE → HELD with a hold id and expiry (e.g. 10 minutes)
3. Payment starts
4. On success: HELD → BOOKED; create booking row
5. On failure/timeout: HELD → AVAILABLE via expiry worker

Narrate concurrency:

"Two users must not both hold the same seat. I'll use a conditional update—only transition if current state is AVAILABLE—or a row lock / serializable transaction per seat or seat group."

Data modeling options

Pick one and defend it; mention the alternative.

5. Payments and idempotency (5 minutes)

• Create a payment intent tied to hold_id / booking_id
• Use idempotency keys so retries don't double-charge
• Confirm booking only on verified payment webhook/callback
• Never mark BOOKED only because the client says payment succeeded

6. Scaling the onsale (5 minutes)

Be honest: display availability can be slightly stale; commit paths must be exact.

7. Failure modes

• Hold expires during payment → fail gracefully, allow retry if seats free
• Payment succeeds but booking write fails → reconciliation job from payment ledger
• Inventory service partition → fail closed on writes (prefer no booking over double booking)

8. Closing tradeoffs

"I'd rather reject a booking than double-sell a seat. Cached seat maps improve read latency at the cost of occasional 'seat just taken' errors at commit time, which we handle with clear UX and retries."

Soft practice note

Ticket booking interviews reward calm state-machine talk under pressure. If you want a structured way to rehearse system design talk tracks and stay composed, Luna Interview is built for rehearsal and prep—before the interview, not as a way around the rules during one.

45-minute checkpoint table

If you remember only one line, make it this: holds are temporary leases; bookings are durable commits; never skip the atomic state check.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.