Ticket Master (Event Ticketing System)¶
Quick Reference Guide for System Design Interviews
Problem Statement¶
Design an event ticketing system like Ticketmaster that handles high-traffic ticket sales, prevents overselling, manages seat selection, and handles flash sales for popular events.
Requirements¶
Functional Requirements¶
- Browse and search events
- View venue seating map
- Select and reserve seats
- Complete purchase within time limit
- Prevent double-booking
- Support waitlists
Non-Functional Requirements¶
- Availability: 99.99%
- Consistency: Strong (no overselling)
- Latency: < 200ms for seat availability
- Scale: 100K concurrent users per event
- Fairness: First-come-first-served
Key Challenges¶
High-Level Architecture¶
Seat Inventory Management¶
Database Schema:
CREATE TABLE seats (
event_id UUID,
seat_id VARCHAR(20), -- 'A-1', 'B-15'
section VARCHAR(20),
row VARCHAR(10),
seat_number INT,
price_tier VARCHAR(20),
price DECIMAL(10,2),
status ENUM('available','reserved','sold'),
reserved_by UUID,
reserved_at TIMESTAMP,
version INT, -- Optimistic locking
PRIMARY KEY (event_id, seat_id)
);
Seat Reservation Flow¶
Virtual Waiting Room¶
Reservation Timeout¶
Preventing Double-Booking¶
Bot Prevention¶
Waitlist System¶
Interview Discussion Points¶
- How do you prevent overselling?
- Distributed locks (Redis)
- Optimistic locking (DB version)
- Unique constraints
-
All three layers for safety
-
How do you handle flash sales?
- Virtual waiting room
- Rate-limited admission
-
Scale backend horizontally
-
How do you handle reservation timeout?
- Delayed queue with Redis ZSET
- Or Redis key expiry notifications
-
Release seats, notify waitlist
-
How do you prevent bots?
- CAPTCHA, rate limiting
- Device fingerprinting
-
Purchase limits
-
How do you ensure fairness?
- Waiting room queue
- First-come-first-served
-
Randomized delays
-
How do you handle payment failures?
- Retry with same reservation
- Extend timeout during retry
- Eventually release if failed