Practice/Amazon/Design a Ticket Booking System

Design a Ticket Booking System

System DesignMust

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 concurrent users. Users expect live seat map availability, fair access during surges, and a smooth checkout with guaranteed ticket delivery.

This is one of the most frequently asked system design questions at Amazon (134 candidate reports). Interviewers ask it because it forces you to reason about extreme contention on a tiny inventory set, short-lived reservation holds with expiration, correctness under retries, and fairness controls such as virtual waiting rooms. It also touches payment orchestration, idempotency, and real-time updates -- skills that map to many high-stakes, stateful product flows beyond ticketing.

Key Requirements

Functional

• Event discovery and search -- users can browse and search for events by keyword, date, location, and category with relevant results
• Seat selection and availability -- users can view ticket availability including interactive seat maps for reserved seating and quantity selectors for general admission
• Temporary hold with checkout -- users can place a short reservation hold on selected tickets (5-10 minutes) that automatically expires if not completed
• Payment and confirmation -- users can complete purchase with payment processing and receive a confirmed booking with digital tickets

Non-Functional

• Scalability -- handle millions of concurrent users during high-demand event launches with thousands of ticket purchases per second
• Reliability -- guarantee no double-selling of tickets even during partial failures; maintain 99.9% uptime with graceful degradation
• Latency -- return availability checks within 200ms, complete booking confirmations within 2 seconds
• Consistency -- strong consistency for ticket inventory to prevent overselling; eventual consistency acceptable for search results and analytics

What Interviewers Focus On

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

1. Inventory Contention and Double-Booking Prevention

Ticket drops concentrate massive write contention on a tiny set of seats or a single GA counter. Multiple users simultaneously attempting to reserve the same seat creates severe race conditions. Your design must atomically update inventory and maintain correctness under concurrent access.

Hints to consider:

• Use conditional writes or compare-and-swap operations to atomically claim a specific seat, preventing two users from booking the same one
• For general admission, use atomic counter decrements (Redis Lua scripts or database conditional updates) to prevent overselling
• Consider optimistic vs pessimistic locking strategies and when each makes sense given contention levels
• Implement idempotency keys so that client retries due to network flakiness don't create duplicate bookings

2. Temporary Hold Mechanism and Expiration

Users need time to complete checkout without others stealing their selection, but holds cannot last forever or inventory gets artificially constrained. Your system must reliably expire abandoned holds.

Hints to consider:

• Create hold records with TTLs in Redis, atomically decrementing available inventory when the hold is created
• Design distributed timer or TTL mechanisms that work across multiple servers and survive failures
• Handle the edge case where a user completes payment just as their hold expires -- use database transactions to verify the hold is still valid
• Make hold expiration idempotent so retries don't corrupt inventory state

3. Admission Control and Fairness During Surges

When tickets go on sale for popular events, uncontrolled traffic can overwhelm the system and create an unfair scramble. Interviewers want to see proactive protection mechanisms.

Hints to consider:

• Implement a virtual waiting room or queue that meters admission to the booking flow during high-demand periods
• Use rate limiting per user to prevent automated bots from monopolizing inventory
• Provide queue position updates and estimated wait times to users waiting in the virtual queue
• Consider circuit breakers and backpressure patterns to protect downstream services during traffic spikes

4. Multi-Step Booking Workflow Orchestration

A complete reservation involves checking availability, creating a hold, processing payment, confirming the booking, and sending notifications. This workflow must be reliable and recoverable.

Hints to consider:

• Model the booking process as a state machine with clear transitions (browsing, holding, paying, confirmed, expired) and compensating actions
• Use the transactional outbox pattern to reliably trigger downstream events like email confirmations and analytics
• Handle payment gateway failures with retries and clear rollback paths that release inventory
• Implement exactly-once booking semantics using idempotency keys tied to the hold ID

Suggested Approach

Step 1: Clarify Requirements

Start by confirming scope and constraints. Ask about expected scale (number of concurrent users during major events, ticket inventory sizes), whether reserved seating with seat maps is required or only general admission, hold duration, and payment integration scope. Clarify consistency requirements: must double-selling be prevented with absolute certainty? Determine if features like waitlists, resale, or group bookings are in scope.