Practice/Google/Design a Ticket Booking System

Design a Ticket Booking System

System DesignMust

Problem Statement

You are designing a ticket booking platform similar to Ticketmaster that handles high-demand events such as concerts, sports games, and theater performances. The system allows users to browse events, view seating maps with real-time availability, select seats, and complete purchases. The central challenge is managing extreme contention on limited inventory -- when a popular artist announces a tour, millions of users may compete for thousands of seats within seconds of tickets going on sale.

The booking flow involves multiple steps: browsing available seats, placing a temporary hold to prevent others from snatching the same seat during checkout, processing payment, and issuing a confirmed ticket. Each step introduces failure modes. Holds can expire, payments can fail or time out, and users may abandon checkout midway. The system must guarantee that no two users ever receive the same seat, while ensuring that abandoned holds are released promptly so inventory is not locked indefinitely.

Beyond the core booking flow, the platform must support secondary market features like waitlists, handle bot traffic attempting to monopolize inventory, and provide event organizers with real-time sales dashboards. The system should scale to handle thousands of events simultaneously while maintaining sub-second response times during peak demand.

Key Requirements

Functional

• Event discovery and seat selection -- Users browse events by category, date, and venue, then view interactive seating maps showing real-time seat availability
• Temporary seat holds -- When a user selects seats, the system places a time-limited hold (e.g., 10 minutes) preventing others from purchasing those seats during checkout
• Payment processing and ticket issuance -- After hold creation, users complete payment; upon success the system issues a confirmed digital ticket with a unique QR code
• Hold expiration and inventory release -- Expired holds automatically return seats to the available pool without manual intervention

Non-Functional

• Scalability -- Support 1M+ concurrent users during high-demand on-sales with 10K+ seat reservation attempts per second
• Latency -- Seat availability queries return in under 200ms; hold creation completes in under 500ms
• Consistency -- Strong consistency for seat inventory to prevent double-booking under any failure scenario
• Reliability -- 99.99% uptime during scheduled on-sale windows; graceful degradation during unexpected traffic spikes

What Interviewers Focus On

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

1. Inventory Contention and Double-Booking Prevention

Thousands of users clicking "buy" on the same seat at the same instant creates severe write contention. Your design must atomically claim inventory and prevent race conditions without sacrificing throughput.

Hints to consider:

• Compare optimistic concurrency control (version checks) with pessimistic locking (row-level locks) and when each approach fits
• Think about how to structure seat data to minimize the scope of locks and reduce conflict windows
• Explore using Redis atomic operations (e.g., SETNX) for fast hold acquisition before writing to the primary database
• Consider whether general availability counters can be managed separately from specific seat assignments

2. Temporary Hold Lifecycle Management

Holds must reliably expire and release inventory even if the server that created them crashes. Users completing checkout just as their hold expires create tricky edge cases.

Hints to consider:

• Design a distributed TTL mechanism that works across multiple servers and survives process failures
• Think about making hold expiration idempotent so retries and race conditions do not corrupt inventory state
• Consider whether expired holds should trigger waitlist notifications or allow other users to grab the seats immediately
• Explore how to handle the race between a user submitting payment and their hold expiring simultaneously

3. Payment Orchestration and Idempotency

The booking workflow spans multiple services (inventory, payment gateway, ticketing). Partial failures at any stage can leave the system in an inconsistent state.

Hints to consider:

• Model the booking process as a state machine with explicit transitions and compensating actions for rollback
• Use idempotency keys on every external call so retries never create duplicate charges or duplicate tickets
• Explore the transactional outbox pattern to reliably trigger downstream events (emails, analytics) after a booking commits
• Think about how to handle payment gateway timeouts where you do not know if the charge succeeded

4. Traffic Shaping and Bot Mitigation

Uncontrolled traffic during on-sales can overwhelm the system, and automated bots attempt to hoard inventory for resale.

Hints to consider:

• Implement a virtual waiting room that queues users before granting access to the booking flow at a controlled rate
• Use rate limiting per user and per IP, combined with CAPTCHA challenges, to slow automated scripts
• Consider randomized admission from the queue rather than strict first-come-first-served to reduce the advantage of faster connections
• Think about providing queue position estimates and wait times to reduce user anxiety and page refreshes

Suggested Approach

Step 1: Clarify Requirements

Confirm the scale parameters: how many concurrent users during a peak on-sale, average and maximum event sizes (seat count), and geographic distribution. Ask about the hold duration and whether it is configurable per event. Clarify payment requirements -- does the platform process payments directly or delegate to a third-party gateway? Confirm whether waitlists, partial seat selection (e.g., "best available"), and secondary market transfers are in scope.