Problems / Design a product, hard

Build BookMyShow

Design BookMyShow from an empty canvas: browse shows and seat maps, hold seats without ever double-booking one, pay, and get a confirmation, even when a blockbuster opens.

Solve it in the lab Take it as a mock interview

Unlock it once for 25 credits; everything inside it is free (runs, changes, Submit, results, hints). Sign in with Google to start; new accounts get free credits.

What it must do

Browse movies, show times and the live seat map of a show.
Hold the seats a customer picks for a few minutes; two customers can never hold the same seat.
Take payment through a payment gateway and confirm the booking.
Send a confirmation (SMS and email) once a booking is paid.

Scale

2,000 requests a second on a normal evening: 1,760 browsing shows and seat maps, 200 seat holds and 40 payments.
40 paid bookings a second is 144,000 bookings an hour at the evening peak.
Seat maps change only when seats are held, so most browsing can be served from a cache.
When bookings open for a blockbuster, traffic jumps to 5× for 8 seconds.

Request types to route: browse (88%, read), hold (10%, write), pay (2%, write). Budget: $48,000 a month.

Estimate first

Seat holds a second when bookings open (5×) (req/s)
Paid bookings an hour at the evening peak (bookings)
Payment gateway calls a month (million)
Monthly cloud cost of your design (USD)

The test cases

You start from an empty canvas. When you run the tests, each one simulates your design with its own traffic and failures:

Test	What it does	Passes when
Normal day	The normal day: the traffic in the brief, nothing broken.	Success ≥ 99.5%; p99 latency ≤ 300 ms (browse); p99 latency ≤ 800 ms (hold); p99 latency ≤ 3.0 s (pay)
Bookings open for a blockbuster	At 5 s bookings open for a blockbuster: traffic jumps to 5× for 8 s, and everyone wants a seat.	Success ≥ 99% (browse); Success ≥ 99% (pay); Success ≥ 55% (hold); p99 latency ≤ 800 ms (hold)
Cache flushed	At 5 s the cache on the request path is emptied, as after a restart or a bad deploy.	Success ≥ 99%; p99 latency ≤ 600 ms (browse)
A server dies	At 4 s one server of the first app service on the request path dies for 10 s.	Success ≥ 99%
Budget: $48,000/month	The normal day's design must cost at most $48,000 a month.	Cost ≤ $48,000/month

Must include

A lock for seat holds. Two people tapping the same seat at the same moment must not both get it: take a short lock on the seats before writing the hold.
A payment gateway. Bookings are paid by card or UPI through a gateway, which is slow and sometimes fails.
A cache for shows and seat maps. Almost nine requests in ten are people looking at the same few shows; serve them from memory, not the database.

What it must do

Scale

Estimate first

The test cases

Must include

More design a product problems