Design a Ticket Booking System

Reference Answer

For a full example answer covering payment orchestration and multi-step transaction workflows, see our Design Payment System guide. The payment guide covers idempotency, saga patterns, and contention handling that apply directly to the checkout flow of a booking system.

Also review the Databases, Message Queues, and Caching building blocks.

Problem Statement

Design a ticket booking system like Ticketmaster that handles high-traffic events, supports both seated and general admission tickets, and manages scenarios like flash sales with limited inventory and thousands of concurrent users competing for the same seats.

Think of concerts, sports events, theater, or airline seats: users discover events, browse a seat map or select a quantity, place a short hold while they complete payment, and receive confirmed digital tickets. The core challenge is extreme contention on a small inventory set during on-sale moments, where thousands of users simultaneously attempt to claim the same seats. The system must prevent double-selling, release abandoned holds reliably, and maintain fairness through admission controls, all while keeping latency low enough to feel responsive.

Key Requirements

Functional

• Event discovery -- Users search for events by keyword, date, location, and category
• Seat selection and availability -- Users view real-time seat maps for reserved seating or available quantities for general admission
• Temporary hold with expiration -- Users place a short reservation hold on selected tickets that automatically expires if checkout is not completed
• Purchase and ticket issuance -- Users complete payment within the hold window, and the system issues confirmed digital tickets

Non-Functional

• Scalability -- Handle 100,000+ concurrent users during peak on-sale moments with 10,000+ transactions per minute across simultaneous events
• Reliability -- Zero tolerance for double-booking; graceful degradation under extreme load
• Latency -- Seat availability checks under 200ms; hold creation under 500ms; responsive experience even under queue admission
• Consistency -- Strong consistency for inventory and reservations; eventual consistency acceptable for search and analytics

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Preventing Double-Booking Under Concurrency

When 10,000 users simultaneously try to claim the same 100 seats, exactly 100 must succeed and 9,900 must be correctly told the seats are taken. This tests your understanding of distributed locking, optimistic concurrency control, and transaction isolation.

Hints to consider:

• Use database row-level locks (SELECT FOR UPDATE) or compare-and-swap with version columns to atomically claim seats
• Evaluate pessimistic locking (simple, correct, but limits throughput) versus optimistic locking (higher throughput but requires retry logic)
• Generate idempotency keys so double-clicks or retried requests do not create duplicate holds or charges
• Partition inventory by event, section, or price tier to reduce lock contention scope

2. Time-Bound Holds and Seat Recycling

Users who select seats but abandon checkout must have their holds released automatically. The system must reliably expire holds and return inventory to the available pool without leaving zombie reservations.

Hints to consider:

• Store hold records with an explicit expiration timestamp and use a background sweeper or TTL-based mechanism to reclaim expired holds
• Consider using Redis keys with TTL for fast expiration detection alongside database records for durability
• Handle the race condition where payment completes just as the hold expires: verify hold validity inside the payment confirmation transaction
• Extend holds when users actively progress through checkout steps (for example, entering payment details) rather than using a single fixed timer

3. Flash Traffic and Admission Control

When a popular artist goes on sale, traffic can spike by orders of magnitude within seconds. Without admission control, the system crashes or becomes unusably slow, creating an unfair experience.

Hints to consider:

• Implement a virtual waiting room that queues users before they reach the booking endpoints, admitting them in controlled batches
• Serve static content (event details, venue maps) from CDN and cache to absorb the read storm without hitting the database
• Rate-limit API calls per session using token-bucket algorithms to throttle automated bots
• Design load-shedding strategies: serve slightly stale availability data from read replicas during extreme peaks

4. Multi-Step Checkout Orchestration

A ticket purchase spans inventory hold, payment authorization, payment capture, ticket generation, and confirmation notification. A failure at any step must not leave the system in an inconsistent state.

Hints to consider:

• Model the checkout as a state machine: available, held, payment-authorized, confirmed, cancelled
• Use the saga pattern with compensating actions: if payment capture fails, release the hold and refund any authorization
• Implement the transactional outbox pattern to reliably publish events (booking confirmed, send email) alongside database writes
• Store every state transition as an immutable event for audit trails and debugging

Suggested Approach

Step 1: Clarify Requirements

Confirm the scope and scale expectations. How many concurrent events does the system need to manage? What is the ratio of browsers to actual purchasers (often 100:1)? Does the system support dynamic pricing or secondary-market resales? What payment methods and fraud checks are required? Are there regulatory requirements? Agree on simplifications: focus on seat holds, payment flow, and consistency first; defer mobile apps and seat recommendations unless time permits.

Step 2: High-Level Architecture

Sketch the core components: an API gateway with rate limiting and waiting-room logic, an inventory service managing seat availability and processing holds, a reservation service tracking hold state and expiration, a payment service integrating with payment processors, a queue service implementing the virtual waiting room, a notification service for emails and push notifications, and the data stores -- Postgres for transactional inventory and orders, Redis for holds and session state, and read replicas for availability queries. Show the data flow: user enters queue, is admitted, checks inventory, creates hold, completes payment, receives confirmation.

Step 3: Deep Dive on Inventory and Hold Management

Walk through the critical path of reserving seats without double-booking. When a user selects seats, the API checks availability using SELECT ... FOR UPDATE, atomically updates seat status to "held," and inserts a hold record with an expiration timestamp in a single transaction. A hold reference is also stored in Redis with a TTL for fast expiration checks. The UI starts a countdown timer. A background worker polls for expired holds every few seconds, transitions them back to "available," and increments the version column. When the user submits payment, the system verifies the hold is still active, authorizes the charge, transitions the seat to "confirmed," and publishes a booking-confirmed event via the outbox pattern.

Step 4: Address Secondary Concerns

Address flash traffic by implementing the waiting room as a sorted set in Redis (or a dedicated queue service) that assigns positions and admits users in batches. Cache seat availability counts aggressively with short TTLs during peaks. Cover the payment flow: authorize first, then confirm seat ownership, then capture payment; if any step fails, compensate. Discuss monitoring: track seats held versus available, hold expiration rate, payment success rate, and queue wait times. Set up alerts for inventory anomalies. Address scaling by sharding the inventory database by event ID and using read replicas for availability queries. If time permits, mention CQRS to separate the write model (strong consistency) from the read model (eventual consistency with cached aggregates).

Real Interview Insights

Candidates at Oscilar and similar companies report that interviewers focus heavily on the contention problem and want a concrete demonstration of how exactly two concurrent requests for the same seat are serialized. One Meta interviewer emphasized improving the user experience after booking is confirmed and the record needs to be persisted. Be prepared to draw the state machine for a reservation lifecycle and explain exactly when locks are held and released.