Design a system where users browse shows, pick seats from a seat map, hold them briefly while paying, and get confirmed tickets — without two users ever getting the same seat, even when a blockbuster opens bookings.

• 500k shows/day × 200 seats = 100M seat-show rows/day; keep 30 days ahead → 3B rows — partition by show.
• Peak: 1M users, one show, 2,000 seats: 1M seat-map reads/min (cache) and maybe 50k hold attempts/s on ~2k rows — extreme contention on a tiny hot set.
• Bookings: 5M/day ≈ 60/s — trivial write volume overall.

GET  /v1/shows/{id}/seats            → seat map with status (available/held/booked), ETag
POST /v1/shows/{id}/holds            { seatIds[], idempotencyKey } → { holdId, expiresAt } | 409 {conflictingSeats}
POST /v1/bookings                     { holdId, paymentMethod }  → { bookingId, status }
DELETE /v1/holds/{holdId}
GET  /v1/bookings/{id}   (QR)
WS   show.{id}.seats  → seat status deltas

shows      (show_id, movie_id, screen_id, starts_at, price_tiers)
seats      (screen_id, seat_id, row, number, tier)
show_seats (show_id, seat_id, status: AVAILABLE|HELD|BOOKED, hold_id, version)   PK (show_id, seat_id)
holds      (hold_id, show_id, user_id, seat_ids[], expires_at, status)
bookings   (booking_id, hold_id UNIQUE, user_id, show_id, amount, status, created_at)
payments   (payment_id, booking_id UNIQUE, ...)

1. Catalogue (movies, theatres, showtimes): read-heavy, cached, served from replicas/CDN.
2. Seat map: served from Redis (show:{id}:seats bitmap/hash) with WebSocket deltas; the DB is the truth, Redis a fast projection updated on every change.
3. Hold (the critical path): one DB transaction: UPDATE show_seats SET status='HELD', hold_id=?, version=version+1 WHERE show_id=? AND seat_id IN (...) AND status='AVAILABLE'; if the updated row count ≠ requested count → rollback, return 409 with the seats that were taken. Row-level locking + the status predicate guarantees no double hold. Hold row written with expires_at.
4. Expiry: a scheduler (or Redis keyspace expiry as a trigger) releases holds past expires_at back to AVAILABLE.
5. Booking: payment via the payment service (idempotent on booking_id); on success, seats move HELD → BOOKED in a transaction that checks hold_id matches and hold not expired.
6. Spike protection: virtual waiting room for hot shows; seat-map reads from cache; holds limited to N seats per user.
7. Partitioning: show_seats partitioned by show_id so a hot show is one partition on one primary — contention is inherent; keep transactions tiny.

Pessimistic vs optimistic: the conditional UPDATE is optimistic concurrency at the row level — no explicit SELECT … FOR UPDATE, no lock ordering issues, and losers fail fast. For hot shows, an alternative is a single-threaded per-show allocator (actor) in memory backed by a write-ahead log, which removes DB contention entirely.

Hold length: 5–10 minutes balances abandonment vs fairness; show a countdown.

Idempotent holds: same idempotencyKey returns the same hold rather than a second one.

Seat map freshness: projection updates go through the same service that commits, in the same request, after the DB commit — small window of staleness, self-corrected by the WS delta.

• Payment succeeds but confirm transaction fails: booking stays pending; reconciliation confirms or refunds; the hold is extended automatically while payment is pending.
• Redis projection stale/lost: rebuild from DB per show on demand; clients tolerate a 409 on hold.
• Scheduler down: holds linger; seats appear unavailable — degraded but safe; alert on oldest unexpired-past-due hold.
• DB primary failover: in-flight transactions roll back; clients retry with the same idempotency key.