Handbooks / System Design Case Studies / Chapter 14

Design a Ticket Booking System like BookMyShow

12 pages · ~19 min✓ Reviewed

Builds on Design a Ride-Hailing App like Uber.

System Design Case StudiesPage 1

Problem Statement, Scope and Requirements (BookMyShow)

1. Scope and Functional Requirements

In scope	Out of scope
Browse cities, theatres, shows	Ads
Pick seats	Reviews
Pay	Food ordering
Get e-ticket	Theatre onboarding UI
Cancel with refund	-

Search shows by city, movie and date
View the live seat map of a show
Hold chosen seats for 8 minutes
Pay, then confirm the booking
Cancel, then refund per policy

2. Scale Estimates

5M bookings/day50M MAU
~60/s average5M / 86,400 s
600/s peak10x in evening hours
~3,300 req/sone blockbuster

System Design Case StudiesPage 2

High-Level Architecture (BookMyShow)

1. The Seven Services

Service	Owns	Store
Catalog	cities, theatres, movies, shows, seat layout	Postgres + CDN
Show and Seat Inventory	seat status, holds, seat-level bookings	sharded Postgres + Redis
Booking	booking record and its states	Postgres

System Design Case StudiesPage 3

Catalog, Shows and Seat Maps (BookMyShow)

1. Responsibilities

Serve cities, theatres, movies and shows (browse is cached and CDN-fronted)
Render a seat map with per-seat status
Seat status is one of AVAILABLE, HELD, BOOKED
Read target: seat map p99 under 200 ms, up to ~3,300 req/s on one blockbuster

2. Design and Flow

Static layout: rows, columns, categories; rarely changes, cached at the CDN

System Design Case StudiesPage 4

Seat Hold with Expiry (BookMyShow)

1. Responsibilities and Design

Reserve up to {6 seats} for 8 minutes while the user pays
Then auto-release the seats if no payment arrives
DB row: hold with status HELD, hold_id, expires_at; the source of truth
Redis key: hold:{show}:{seat} with TTL 480 s, only a fast release signal

Hold is a status, never a DB lock held for 8 minutes
Max 6 seats per hold, all-or-nothing

System Design Case StudiesPage 5

Preventing Double Booking (BookMyShow)

1. The Invariant and the Last Guard

One (show_id, seat_id) can be BOOKED by at most one booking
Enforce it in the database, never only in app code
App checks can be bypassed by a bug, a retry or a second service

Last safety net: unique constraint on booking_seat(show_id, seat_id)
A buggy path then fails with a duplicate-key error instead of double booking
On cancel, delete the booking_seat rows so the seat can be sold again

System Design Case StudiesPage 6

Payments and Booking Confirmation (BookMyShow)

1. Responsibilities and Design

Charge the user for a hold (hold_id, 8 min window)
Confirm the booking exactly once
Issue the ticket with a QR code
Payment service wraps UPI, card, wallet behind one interface
The gateway webhook confirms success, not the browser redirect

2. Confirmation Flow

Intentpayment for hold_id
Redirectuser pays at gateway
WebhookHMAC verified
One DB txnseats BOOKED, booking CONFIRMED
Eventemit BookingConfirmed

System Design Case StudiesPage 7

Virtual Queue for High-Demand Releases (BookMyShow)

1. Role and Design

Shield Inventory and Payment from a flash crowd of 1M users
Admit fairly: first come, first served, in controlled batches
Queue sits in front of the booking flow, not inside it

Enabled per movie by ops, or auto-on when requests pass 2,000/s
Waiting page and status reads: served from the CDN edge
Queue order: Redis sorted set
Normal movies skip the queue entirely

System Design Case StudiesPage 8

Cancellations and Refunds (BookMyShow)

1. Responsibilities and Policy

Let users cancel before a cutoff
Release the seats back to inventory
Return money per policy, to the original payment method
Theatre-cancelled show: refund 100% automatically, no user action

When	Refund
Until 4 h before showtime	100% of ticket price

System Design Case StudiesPage 9

Notifications and Ticket Delivery (BookMyShow)

1. Responsibilities and Design

Send booking confirmation and the QR ticket after payment
Send show reminders and cancellation / refund updates
Channels: push, SMS, email

Kafka topicsBookingConfirmed, BookingCancelled, RefundProcessed
Consumersone group per topic
Channel workerspush, SMS, email
Providerprimary, then fallback

System Design Case StudiesPage 10

Scaling, Failure Handling, Trade-offs and Interview Questions (BookMyShow)

1. Scale and the Hot Show

Shard the seat store by show_id: one show is one shard, so no cross-shard transactions
Read replicas and Redis serve seat maps; writes go only to the shard primary
5M bookings/day = ~60/s avg, 600/s peak: fits a few Postgres shards
Per-show seat rows: 10M seat rows/day across all shows

Routerhash(show_id)
Shard primaryholds, bookings
Replicas + Redisseat-map reads

System Design Case StudiesPage 11

Cheatsheet: Movie Ticket Booking Design (BookMyShow)

1. States and Numbers

AVAILABLEfree
HELD8 min TTL
BOOKEDpaid

CONFIRMED
CANCELLING
CANCELLED
REFUNDED

Number	Value
Bookings, average	60/s
Bookings, evening peak (10x)	600/s

System Design Case StudiesPage 12

Check yourself

Spot the bug: two users click seat 12 of show 7 at the same instant. Both calls run the code below. What can happen, and what is the fix?

Both SELECTs can return AVAILABLE before either UPDATE runs, so both users get a hold: a check-then-update race.
The UPDATE has no condition on status, so the second one silently overwrites the first.
Fix: one conditional statement, UPDATE ... SET status='HELD' WHERE show_id=7 AND seat_id=12 AND status='AVAILABLE'.
Rows affected = 1 means you won the seat. Rows affected = 0 means you lost the race, so reject that user.
The unique (show_id, seat_id) on booking_seat stays as a last safety net, not as the main guard.

SELECT status FROM show_seat WHERE show_id=7 AND seat_id=12;
-- app code: if status == 'AVAILABLE' ...
UPDATE show_seat SET status='HELD' WHERE show_id=7 AND seat_id=12;

Estimate	Math	Result
Booking data	5M x 1 KB	5 GB/day
Booking data per year	5 GB x 365	~1.8 TB/year
Seat rows	10,000 screens x 5 shows x 200 seats	10M rows/day

Step	Mode	Why
Seat hold	sync	user needs yes/no now; p99 under 100 ms
Payment init	sync	user needs the gateway link now
Ticket email / SMS	async, Kafka	can lag a few seconds
Invoice	async, Kafka	not on the user's critical path
Analytics	async, Kafka	best-effort, replayable

Table	Columns
`movie`	id, title, lang
`theatre`	id, city_id
`screen`	id, theatre_id, layout_json
`show`	id, screen_id, movie_id, start_time, price_tier
`show_seat`	show_id, seat_id, status, version

Metric	Target
Seat-map latency	p99 under 200 ms
CDN + Redis cache hit ratio	above 95%
Stale-map click rejection rate	tracked; a spike means the poll is too slow

Event	Seat state	Redis key
Hold placed	AVAILABLE → HELD	set, TTL 480 s
Payment success	HELD → BOOKED	deleted
Expiry or cancel	HELD → AVAILABLE	expires or deleted

API	Does
`POST /holds`	hold seats, returns `hold_id`, `expires_at`
`DELETE /holds/{id}`	cancel, seats back to AVAILABLE
`POST /holds/{id}/extend`	+2 min, allowed once, during payment

Guard	Wins when	Catch
Optimistic conditional UPDATE	Low contention, most seats uncontested	Losers must retry or pick other seats
Pessimistic `FOR UPDATE`	Many users fight for the same seats	Waiters queue on the lock for a few ms
Redis SETNX	Cheap front filter to shed losers early	Not durable: never the source of truth

Endpoint	Rule
`POST /payments`	`Idempotency-Key` header, a retry returns the same intent
`POST /webhooks/gateway`	verify the HMAC over the raw body before parsing or acting on it
`GET /bookings/{id}`	booking status plus ticket QR

Metric	Target
Payment success rate	above 92%
Webhook-to-confirm latency	under 2 s
Ticket delivery p99	under 10 s
Auto-refund count	tracked, alert on a spike

Item	Detail
`queue:{movie}`	ZSET, score = arrival timestamp, member = `user_id`
Admission token	signed JWT with `movie_id` and expiry (10 min)
`POST /queue/join`	returns position; safe to repeat
`GET /queue/status`	returns position and ETA (or the token when admitted)
Booking APIs	reject any request without a valid token

Metric	Target / meaning
Queue length	drains toward 0
Admit rate vs booking success rate	admit must not outrun success
Time in queue	p95 tracked
Abandon rate	users leaving the queue
5xx on Inventory	stay under 0.1%

API	Does
`POST /bookings/{id}/cancel`	starts the cancel flow
`GET /refunds/{id}`	refund status
Refund destination	original payment method
Refund time	3 to 7 days to reach the user

Failure	Response
SMS provider down	Fail over to a second provider after 3 attempts
Duplicate event	Dedupe on (booking_id, type), so no double send
Consumer crash	Kafka redelivers; the dedupe makes the retry safe

Metric	Target
Confirmation delivered	within 10 s for 99%
Delivery failure rate	under 1%
Consumer lag	under 5 s

Decision	We choose	Why	Price paid
Seats: consistency vs availability	Consistency	An oversold seat is worse	A booking may briefly fail
Hold TTL length	8 minutes	Covers slow UPI payments	Seats stay locked a bit longer
Shorter TTL	Not chosen	Frees seats faster	Loses slow payers

Design a Ticket Booking System like BookMyShow

1. Scope and Functional Requirements

2. Scale Estimates

1. The Seven Services

1. Responsibilities

2. Design and Flow

1. Responsibilities and Design

1. The Invariant and the Last Guard

1. Responsibilities and Design

2. Confirmation Flow

1. Role and Design

1. Responsibilities and Policy

1. Responsibilities and Design

1. Scale and the Hot Show

1. States and Numbers

3. Non-Functional Targets and Storage

2. Read Path vs Write Path

3. Sync vs Async

4. Monolith or Microservices

3. Tables and APIs

4. Failure and Metrics

2. Seat States and Flow

3. Tables and APIs

4. Failures and Metrics

2. Claiming Seats: Which Guard

3. Common Mistakes

3. Tables and APIs

4. Failures and Metrics

2. Join, Wait, Admit

3. Data and APIs

4. Failures and Metrics

2. Cancel Flow

3. Tables and APIs

4. Failures and Metrics

2. Delivery Flow

3. Tables and APIs

4. Failures and Metrics

2. Failure Handling

3. Trade-offs

4. Interview Qs and Mistakes

2. Double Booking and Confirmation

3. Queue and Refunds