Designing a Ticket Booking System

Selling 10,000 tickets to 10,000,000 users in 5 minutes is one of the hardest concurrency problems in engineering.

1. Requirements

Functional

• Search: View available seats.
• Select: Click a seat to temporarily hold it.
• Pay: Complete purchase within 5 minutes.

Non-Functional

• Fairness: First Come, First Served (FCFS).
• No Double Booking: Crucial. Two people cannot buy Seat 1A.
• Scalability: Handle 1M+ Requests Per Second (RPS) during "The Drop".

2. The Core Problem: Race Conditions

Imagine a SQL table seats with status='AVAILABLE'.

1. User A checks Seat 1A: SELECT status ... -> Returns 'AVAILABLE'.
2. User B checks Seat 1A: SELECT status ... -> Returns 'AVAILABLE'.
3. User A Buys: UPDATE seats SET status='SOLD' WHERE id='1A'.
4. User B Buys: UPDATE seats SET status='SOLD' WHERE id='1A'.

Both users think they own the ticket. User B overwrites User A. This is a Default (Read Committed) isolation failure.

3. Database Locking Strategies

Solution 1: Pessimistic Locking (SELECT FOR UPDATE)

We lock the row when reading it.

• START TRANSACTION;
• SELECT * FROM seats WHERE id='1A' FOR UPDATE; (User B blocks here).
• UPDATE seats ...
• COMMIT;
• Problem: Terrible performance. Database locks are expensive. If User A's internet dies, the lock is held until timeout.

Solution 2: Optimistic Locking (Versioning) - Recommended

We add a version column to the row.

1. User A reads Seat 1A (Version 1).
2. User B reads Seat 1A (Version 1).
3. User A writes: UPDATE seats SET status='SOLD', version=2 WHERE id='1A' AND version=1.
   • Result: 1 Row Affected. Success.
4. User B writes: UPDATE seats SET status='SOLD', version=2 WHERE id='1A' AND version=1.
   • Result: 0 Rows Affected. (DB sees version is now 2, not 1).
   • Action: Tell User B "Sorry, someone beat you."

4. Architecture: The Booking Flow

We cannot let 10 Million users hit the Postgres DB directly.

Step 1: The Waiting Room (Virtual Queue)

Before you even see seats, you enter a queue.

• Tech: AWS Lambda + Redis Sorted Set / Kafka.
• Logic: Only allow 500 users per second to enter the "Booking Area".
• Benefit: Protects the database from "The Thundering Herd".

Step 2: Temporary Hold (Redis)

When a user clicks "Seat 1A", we don't write to SQL yet. We write to Redis.

• SET seat_1A_lock user_id NX EX 300
  • NX: Only set if not exists (Atomic lock).
  • EX 300: Expire in 300 seconds (5 minutes).
• If Redis returns OK, show "Time Remaining: 5:00" timer.
• If Redis returns NULL, show "Seat taken".

Step 3: Payment & Final Commitment

User enters credit card info.

1. Payment Service: Charge card. Success.
2. Booking Service: Now we persist to SQL.
   • UPDATE seats SET status='SOLD', owner='UserA' WHERE id='1A'.
3. Cleanup: Delete Redis key (or let it expire).

5. Handling Data Consistency

What if Redis says "Locked" but the SQL Database crashes?

• Reconciliation Worker: A background job checks:
  • "Is this seat locked in Redis for > 5 mins?" -> Release it.
  • "Is this seat 'SOLD' in SQL but 'Open' in Redis?" -> Sync them.

6. DB Partitioning (Sharding)

A single Postgres instance can't handle 100k writes/sec.

• Shard by Event ID: All seats for "Taylor Swift NYC" live on Shard 1.
• Risks: "Hot Shard" problem. If everyone wants Taylor Swift, Shard 1 melts while Shard 2 is empty.

Summary

1. Queue: Throttle users before they reach the DB.
2. Fast Lock: Use Redis SET NX for the 5-minute hold.
3. Safe Write: Use Optimistic Locking (Version #) for the final SQL commit.