Design movie ticket booking (BookMyShow)

The core invariant is that a seat is BOOKED by at most one booking. Make a hold an atomic conditional write over all requested seats: a single UPDATE with WHERE status='AVAILABLE' on rows of one show (one shard), and compare the affected row count with the number of seats. Row locks inside the database serialise two users racing for C7; one wins, the other sees zero rows and gets a fresh map. Hold for all-or-nothing so a family of four does not end up with three seats. Holds expire after ~8 minutes. Use two mechanisms: a Redis key with TTL or a delay queue that triggers release at expiry, and a sweeper that releases any row with hold_expires_at < now() as a safety net. Release must be conditional too (WHERE hold_id=? AND status='HELD'), so a late release never frees a seat that was just booked. Some teams use Redis SET NX per seat as the lock; that is fast but you then have two sources of truth. If you use it, the database write is still the commit point. A per-show actor or single-writer queue is an option for stadium events with very high contention on one show.

Payment is the slowest and least reliable step: UPI approval can take a minute, and webhooks can arrive after the hold expired. Design for three outcomes. Normal: the webhook arrives in time, and a single transaction converts HELD to BOOKED where hold_id matches and marks the booking CONFIRMED. Late: the hold expired and seats were released. Try to re-hold the same seats; if someone else took them, refund automatically and tell the user clearly. Unknown: no webhook arrives. A reconciliation job polls the gateway for PENDING bookings after a few minutes and settles them the same way. Extend the hold once payment has started (for example to 15 minutes) so a slow UPI approval does not lose seats. Use an idempotency key on booking creation and dedupe webhooks by payment_id. Never confirm a booking before the gateway says the money is captured, and keep the refund path automatic because manual refunds generate support tickets and social media complaints within minutes.

When a big concert or a superstar's film opens bookings, a million people arrive in minutes, many refreshing repeatedly. Scaling the seat service to absorb that is wasteful and still unfair. Put a waiting room in front: users who arrive before the sale opens are given random positions (so being early by a second gives no advantage over being early by a minute), and later arrivals queue FIFO. The queue lives in Redis (sorted set by position) or a managed service; the page polls its position every ~10-20 seconds from a CDN-cacheable endpoint. An admitter releases users at a fixed rate tuned to what the seat service handles comfortably, issuing a signed token (JWT with event_id, user_id, expiry). The gateway checks the token on every seat and booking call, so bots cannot skip the queue. Limit tickets per account and per payment instrument, require login and OTP-verified phone numbers, and show the expected wait. When seats sell out, tell everyone still in the queue immediately instead of letting them wait.

During a rush thousands of users watch the same show's seat map. Reading 300 rows from Postgres per view would overload the shard. Keep a compact seat status array per show in Redis (one byte or two bits per seat) with a version number. Every hold, release or booking for that show updates it after the database commit; a view is a single Redis GET of a few hundred bytes. The layout (rows, gaps, categories) is static and cached on the CDN, so only status travels. The map can be a second stale; that is fine because the hold API is the real check and returns the fresh map on conflict. For live updates, clients can poll with the version (304 if unchanged) or subscribe via SSE for very hot shows. For inventory owned by a cinema's own system, cache their availability for a few seconds and accept more conflicts at hold time.

Database: one source of truth, transactional across seats, simpler recovery; enough for a few thousand holds/s across sharded shows. Redis SET NX per seat: faster under extreme contention, but needs a second write to the database and careful handling when they disagree. Start with the database; add Redis locks only for stadium-scale events.

Holding first gives the user certainty about seats and avoids refunds, at the cost of seats being locked by people who abandon. Paying first wastes fewer seats but causes many refunds when the seats are gone. Hold with a short TTL, and extend once payment starts.

Where the cinema runs its own ticketing system, it is the source of truth because box office also sells seats. The platform must call its lock and commit APIs, which are slower and less reliable. Where cinemas give the platform an allocation, inventory is direct and fast. Support both behind one inventory interface.

A single stadium show with 50k seats concentrates all writes on one shard. Partition the show's inventory by section (each section is its own row group or actor), have the UI choose a section first, and admit users through the waiting room at a rate the shard can handle.

Thousands of payments per minute can hit gateway rate limits. Use multiple gateways with routing by success rate, and keep holds alive during payment so gateway slowness does not lose seats.

Expired holds keep seats unavailable longer than needed, but no double booking happens. The hold API also treats a seat whose hold_expires_at has passed as available (WHERE status='AVAILABLE' OR hold_expires_at < now()), so correctness and availability recover even without the sweeper.

Treat the external lock as unknown: retry with the same request ID, and if still unknown, release on our side and tell the user to retry. A background reconciler fetches the cinema's state and releases orphaned locks. Circuit-break per cinema chain so one slow chain does not exhaust threads.

The reconciliation job finds payments without confirmed bookings and either confirms (if seats are still held) or refunds. Alert when this rate rises, because it usually means webhook delivery is broken.