System Design: Designing Ticketmaster
The primary challenge of a system like Ticketmaster or Booking.com is not storage, but Concurrency. How do you ensure that when 100,000 users try to book the same 10 front-row seats, only 10 people succeed and no seat is double-booked?
1. Core Requirements
- Search: Find events and available seats.
- Reservation: Hold a seat for 5-10 minutes while the user completes payment.
- Booking: Finalize the seat purchase.
- Scalability: Handling massive traffic spikes when a popular concert goes on sale.
2. The Reservation Challenge
We need a "Soft Hold" on seats to prevent others from booking them while a transaction is in progress.
Option A: Pessimistic Locking (Database)
- Logic:
SELECT * FROM seats WHERE id = 123 FOR UPDATE. - Pros: Strong consistency, easy to implement in SQL.
- Cons: Extremely slow. Holding database locks for millions of concurrent users will crash your DB.
Option B: Distributed Locking (Redis)
- Logic: Use Redis to manage the seat status. When a user selects a seat, we set a key in Redis with a TTL of 10 minutes:
SET seat:123:hold user:456 NX EX 600. - Pros: Blazing fast, handles massive concurrency, handles "Auto-release" via TTL.
3. Handling the "Thundering Herd"
When a superstar's tour is announced, millions of users hit the "Search" and "Book" buttons at the exact same millisecond.
- Virtual Waiting Room: Use a queue (like AWS SQS or a custom Redis-based queue) to regulate traffic. Instead of everyone hitting the DB, users are given a "queue position" and processed at a rate the backend can handle.
4. Database Selection
- Inventory/Seats: PostgreSQL or MySQL (ACID is non-negotiable for the final payment transaction).
- Caching/Holding: Redis for fast state management.
- Event Metadata: DynamoDB or MongoDB for flexible concert details.
5. Ensuring "Exactly Once" Payment
- Idempotency Keys: Every booking request must include a unique client-side generated key. If the user clicks "Pay" twice, the server detects the duplicate key and doesn't charge the card twice.
6. Global Scale: Read Replicas and CDNs
Event information (artist bio, venue map, dates) doesn't change frequently.
- CDN: Cache event metadata at the edge.
- Read Replicas: Use globally distributed read replicas to handle search traffic, keeping the primary database free for critical write operations (booking).
Summary
Designing Ticketmaster is an exercise in managing scarcity. By using Redis for distributed locks and a virtual waiting room to smooth out traffic spikes, you can build a system that maintains 100% data integrity even under extreme load.
