How does BookMyShow prevent double booking?

The short answer: Distributed Locking with Redis.

When you select a seat, the system creates a temporary, time-limited lock in a high-speed cache (Redis) using the SET ... NX command.

This ensures that even if two users click at the exact same millisecond, the single-threaded nature of Redis guarantees only one request succeeds. The "loser" receives an immediate error without overloading the main database.

lightbulb Core Concepts

  • check_circle Pessimistic Locking: Seats are locked immediately upon selection.
  • check_circle TTL (Time-To-Live): Locks auto-expire (e.g., 10 mins) if payment fails.
  • check_circle Atomicity: Redis operations are atomic; race conditions are impossible at the key level.

Concurrency Lab

Interactive simulation of two users racing for the same seat.

User A (Alice) wifi

Avengers: Endgame

IMAX 3D • Today, 7:00 PM

SCREEN THIS WAY

dns Backend System

REDIS CACHE
// Empty (No Locks)
database POSTGRESQL
seat_id status user
A1 AVAILABLE NULL
Server Logs (Tail -f)
[SYSTEM] Server ready. Waiting for requests...
User B (Bob) wifi

Avengers: Endgame

IMAX 3D • Today, 7:00 PM

SCREEN THIS WAY

school The Deep Dive

1. Why Redis? (Speed vs. Consistency)

Checking a traditional SQL database for seat availability every time a user taps a seat is too slow for millions of users. Redis is an In-Memory store, meaning it reads/writes in microseconds.

BookMyShow uses Redis for the "Selection Phase" to handle the high throughput. The main SQL database is only hit when the payment is actually confirmed.

2. The SET NX Command (The Magic)

The core mechanism preventing double booking is the atomic Redis command:

SET seat_12345 user_id_99 NX EX 600
  • NX (Not Exists): Only set this key if it does not already exist. If two users try simultaneously, Redis guarantees only one succeeds. The other gets a 0 (false).
  • EX 600: Automatically expire (delete) this key after 600 seconds (10 minutes). This handles cases where a user closes their browser without paying.

3. Optimistic vs. Pessimistic Locking

Pessimistic (Used Here)

"I lock this seat so no one else can touch it while I decide."

Great for user experience (no disappointment at checkout), but can leave seats empty if users abandon carts.

Optimistic

"I'll let everyone try to book, and check for conflicts only at the final payment step."

Better for system performance, but frustrating for users ("Sorry, seat taken" errors at payment).