Ticket Booking System (Ticketmaster)

Overview

Introduction
Requirements
Data Model
API Design
Handling Concurrency & Double Booking
Handling Massive Traffic Spikes (The "Taylor Swift" Problem)
Managing "Held" Tickets (Expiration & Cleanup)
Complete Architecture
Additional Discussion Points

Introduction

Designing a ticket booking system is a classic system design problem that tests a candidate's ability to handle high concurrency and burst traffic. Unlike standard e-commerce platforms, ticket booking systems face a unique challenge: inventory is finite, immovable (a specific seat at a specific time), and demand is often extremely "spiky" (e.g., a Taylor Swift concert sale).
The core conflict in this design is between Consistency (preventing double bookings) and Availability/Latency (handling millions of users trying to buy the same tickets simultaneously).

Requirements

Functional Requirements
- Search & View: Users can search for events (by artist, location, genre) and view event details.
- Seat Selection: Users can view a seat map and select specific available seats.
- Booking (Reservation): Users can temporarily "hold" tickets while they proceed to payment.
- Payment & Confirmation: Users pay for the held tickets to confirm the booking.
Non Functional Requirements
- Strong Consistency: Enforce strict ACID guarantees on seat inventory (linearizability) so no single seat is ever double-booked
- High Availability: Target 99.99% uptime for the browsing/search path; 99.9% for the booking path.
- Scalability (Burst Handling): Handle extreme burst traffic of 1M+ concurrent users, 100k seat view requests/sec, and 10k write transactions/sec during ticket drops.
- Fairness: Ensure strict First-Come-First-Served (FCFS) order processing for users entering the booking flow from the waiting room.

Data Model

For a system requiring ACID compliance on inventory, a Relational Database (RDBMS) like PostgreSQL or MySQL is preferred for the core booking data. However, for search and caching, we will use NoSQL and in-memory stores.

Key Entities (SQL)

Event: id, name, description, venue_id, start_time, end_time
Venue: id, name, location, seat_map_config
Seat: id, venue_id, row, number, type (VIP, Regular)
Event_Seat: id, event_id, seat_id, status (AVAILABLE, RESERVED, BOOKED), price, booking_id
Booking: id, user_id, event_id, status (PENDING, CONFIRMED, CANCELLED, EXPIRED), created_at, expires_at

NoSQL/Cache

Elasticsearch: For full-text search on Events.
Redis: For caching active seat maps, storing temporary "locks" on seats, and user sessions.

API Design

For a hotel booking system we will use a classic RESTful API to interact with the data. RESTful APIs are simple, widely used, stateless, and support caching which make it a good candidate for our system.

Our REST API will comprise of four main endpoints:

GET /api/events?query={...}: Search events (Elasticsearch).
GET /api/events/{id}/availability: Retrieves the Dynamic Overlay
- Response: Compressed Binary Bitfield (or Base64 blob) mapped to seat IDs (0=Free, 1=Taken)
POST /api/bookings/reserve: Critical Endpoint.
- Payload: { event_id, seat_ids[] }
- Response: { booking_id, expires_at } or Error (Seats taken).
POST /api/bookings/{id}/payment: Process payment.
- Payload: { payment_token }

High Level Design

At a high level, the system is split into a Read Path (Browsing) and a Write Path (Booking).

Client:
- The user interface (Web/Mobile) optimized for high-concurrency interactions.
CDN:
- Serves static assets like venue images, JavaScript bundles, and specifically seat map templates (e.g., the SVG layout of a stadium) to reduce load on backend servers.
Load Balancer:
- Distributes incoming HTTP/S traffic across availability zones. Terminates SSL and handles initial DDoS mitigation.
API Gateway:
- The entry point for all client applications. Handles authentication (JWT), rate limiting (leaky bucket), request validation, and circuit breaking to protect downstream services from cascading failures.
Search Service (Read Path):
- A high-throughput service backed by Elasticsearch. It handles complex queries ("concerts in NYC this weekend") and provides event metadata. It is eventually consistent, receiving updates via a sidecar indexer or CDC stream to avoid locking the primary database.
Seating Cache (Redis - Bitfields):
- Utilizes highly space-efficient bitfields (1 bit per seat) to store real-time availability. This cluster acts as the authoritative Data Origin for the CDN. When the edge cache expires, the system fetches the latest binary state from here to ensure clients receive fresh data.
Booking Service (Write Path):
- The transactional heart of the system. It handles the state machine for seats (Available → Reserved → Booked). It enforces ACID compliance using database transactions to prevent double-booking.
Active Reservation Service (Redis):
- Acts as a Distributed Lock Manager. It stores temporary "holds" on seats using TTL (Time-To-Live) keys. If a user selects a seat, this service quickly sets a key (e.g., seat_123: locked_by_user_456) to block other buyers before the request even hits the slower SQL database.
Payment Service:
- Orchestrates payments with external providers (Stripe/PayPal/Adyen). Crucially, it handles idempotency keys to ensure users aren't charged twice if network timeouts occur and manages the "reversal" logic if a payment fails.

Handling Concurrency & Double Booking

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.