Design a Ticket Booking System

Problem Low-level design of a ticket booking system (movie/event style): browse shows, view seat availability, hold and book seats, pay.

Requirements

• Entities and API: searchShows(city, date), getSeatMap(showId), holdSeats(showId, seatIds, userId) with a TTL, confirmBooking(holdId, payment), cancelBooking(bookingId).
• No double-booking under concurrent holds; expired holds release seats automatically.

Core design

• Classes: Venue → Screen → Seat; Show (screen + time + pricing); SeatHold(showId, seats, userId, expiresAt); Booking(hold → confirmed, payment reference); services: ShowService, BookingService, PaymentService.
• Seat state machine per show: AVAILABLE → HELD → BOOKED (holds expire back to AVAILABLE). Central invariant: a seat has at most one active hold/booking per show.

Discussion points

• Concurrency for seat locking: pessimistic (row locks / synchronized seat map) vs optimistic (version check on confirm) — and how a distributed deployment changes this (DB constraints or Redis SETNX with TTL for holds).
• CAP framing: booking confirmation favours consistency over availability; seat-map browsing can be eventually consistent.
• SOLID in the design: single responsibility per service, strategy for pricing/payment, open/closed for new seat types or channels.
• Hold-expiry implementation: scheduled sweep vs lazy expiry on access vs delay queue.