Requirements

Functional Requirements

• Users can browse events and view available seats
• Users can select seats and hold them temporarily (5-minute window)
• Users can complete purchase with payment
• Seats are released if payment not completed within hold window
• Support for different seat categories and pricing
• Users can view their booking history

Non-Functional Requirements

• Consistency: No double-booking under any concurrency level
• Availability: 99.99% uptime during onsale events
• Latency: Seat selection response < 200ms
• Scalability: Handle 1M concurrent users for a single event

Back-of-the-Envelope Estimation

High-Level Architecture

Detailed Design

Seat Reservation Flow

The seat reservation is the critical path. Use optimistic locking or distributed locks to prevent double-booking:

Seat State Machine

Hold TTL Mechanism

Use Redis with TTL for automatic seat release:

Database Schema

CREATE TABLE seats (
    id          BIGINT PRIMARY KEY,
    event_id    BIGINT NOT NULL,
    section     VARCHAR(20),
    row         VARCHAR(5),
    number      INT,
    status      VARCHAR(10) CHECK (status IN ('available', 'held', 'booked')),
    held_by     BIGINT,
    held_until  TIMESTAMP,
    version     INT DEFAULT 0,
    price       DECIMAL(10, 2)
);

CREATE INDEX idx_event_seats ON seats(event_id, status);
CREATE UNIQUE INDEX idx_seat_unique ON seats(event_id, section, row, number);

Handling Flash Sales

For high-demand events with millions of concurrent users:

1. Users enter a virtual queue when onsale starts
2. Queue processes 1000 users at a time
3. Each user gets a 5-minute booking window
4. If not booked, user re-enters the queue

Practice Exercises

1. Concurrency: If two users try to book the same seat simultaneously, design the exact sequence of database operations to prevent double-booking.

2. Scale: For an event with 50,000 seats and 1M concurrent users, estimate the Redis memory needed for seat holds and the database write throughput.

3. Reliability: What happens if the payment service goes down while users have held seats? Design a recovery mechanism that doesn't lose money or double-book.

4. Optimization: How would you implement a seat selection UI that shows real-time availability to millions of users without overwhelming the backend?

What to Learn Next