TLDR: A Movie Booking System (like BookMyShow) is an inventory management problem with an expiry: seats expire when the show starts. The core engineering challenge is preventing double-booking under concurrent user load with a 3-state seat model (AVAILABLE → LOCKED → BOOKED).

---

📖 The Cinema Inventory Problem: What Makes It Hard

You run a cinema. A Friday night show has 200 seats. Two scenarios break a naive implementation:

1. Double-booking: User A and User B click "Book Seat A1" at the same millisecond. Only one should succeed.
2. Abandoned locks: User A locks Seat A1 but never completes payment. The seat should become available again after 10 minutes.

This needs a 3-state model + distributed lock strategy.

---

🔢 The Domain Hierarchy: City → Cinema → Screen → Show → Seat

classDiagram
    class City { +String name; +List~Cinema~ cinemas }
    class Cinema { +String name; +List~Screen~ screens }
    class Screen { +int id; +List~Seat~ seats }
    class Movie { +String title; +int durationMinutes }
    class Show {
        +Movie movie
        +Screen screen
        +LocalDateTime startTime
        +synchronized boolean bookSeats(List seats)
    }
    class Seat {
        +String row
        +int col
        +SeatType type
        +SeatStatus status
    }
    class Booking {
        +int id
        +Show show
        +List~Seat~ seats
        +PaymentStatus payment
    }

    City *-- Cinema
    Cinema *-- Screen
    Screen *-- Seat
    Show --> Screen
    Booking --> Show
    Booking --> Seat

• SeatType: GOLD, SILVER, PLATINUM — affects pricing.
• SeatStatus: AVAILABLE, LOCKED, BOOKED — the concurrency core.
• Show is the intersection of Movie + Screen + StartTime.

---

⚙️ The 3-State Seat Model: Preventing Double Booking

The key insight: don't go directly from AVAILABLE to BOOKED. Insert a temporary LOCKED state.

State machine:

stateDiagram-v2
    [*] --> AVAILABLE
    AVAILABLE --> LOCKED : User selects seat (10 min TTL)
    LOCKED --> BOOKED : Payment success
    LOCKED --> AVAILABLE : Payment timeout / failure
    BOOKED --> [*] : Show complete

The booking flow:

User B gets a graceful "This seat is currently being held by another user" message — not a race condition with undefined behavior.

---

🧠 Java Implementation: Synchronized Booking

public class Show {
    private final int id;
    private final List<Seat> seats;

    public synchronized BookingResult reserveSeats(User user, List<Integer> seatIds) {
        // Phase 1: Check all requested seats are available
        List<Seat> selected = new ArrayList<>();
        for (int id : seatIds) {
            Seat s = findSeat(id);
            if (s.getStatus() != SeatStatus.AVAILABLE) {
                return BookingResult.failure("Seat " + id + " is not available");
            }
            selected.add(s);
        }
        // Phase 2: Lock all seats together (atomic within synchronized block)
        Instant lockExpiry = Instant.now().plusSeconds(600);
        for (Seat s : selected) {
            s.setStatus(SeatStatus.LOCKED);
            s.setLockExpiry(lockExpiry);
        }
        return BookingResult.success(new Booking(user, this, selected));
    }
}

synchronized on the Show method ensures that the check-and-lock is atomic — no two threads can interleave between the check (AVAILABLE) and the lock (LOCKED).

---

⚙️ Pricing Strategy Pattern

Different shows and seat types need different prices:

public interface PricingStrategy {
    double calculatePrice(Show show, Seat seat);
}

public class HourlyPricing implements PricingStrategy {
    public double calculatePrice(Show show, Seat seat) {
        double base = seat.getType() == SeatType.GOLD ? 15.0 : 10.0;
        return show.isWeekend() ? base * 1.2 : base;  // weekend surcharge
    }
}

public class DynamicPricing implements PricingStrategy {
    public double calculatePrice(Show show, Seat seat) {
        double occupancy = show.getBookedPercent();
        return BASE_PRICE * (1 + occupancy);  // price rises with demand
    }
}

---

⚖️ Scaling the Booking System

The synchronized approach works for a single JVM. At scale:

---

📌 Summary

• 3-state seat model (AVAILABLE → LOCKED → BOOKED) prevents double-booking and handles abandoned checkouts.
• synchronized bookSeats() makes the check-and-lock atomic; no two users can hold the same seat.
• Strategy Pattern for pricing decouples business rules from booking logic.
• Distributed scale moves from JVM synchronized to Redis SETNX or DB CAS.

---

📝 Practice Quiz

1. Why is a 3-state model (AVAILABLE → LOCKED → BOOKED) better than a 2-state model (AVAILABLE → BOOKED)?

   • A) It reduces database writes.
   • B) The LOCKED state holds the seat for the user during payment without permanently booking it, allowing auto-release on timeout.
   • C) It's required by cinema software standards.
     Answer: B

2. In the single-server Java implementation, what prevents two threads from both seeing a seat as AVAILABLE and both locking it?

   • A) volatile on the seat status field.
   • B) synchronized on bookSeats() — only one thread executes the check-and-lock block at a time.
   • C) A database constraint.
     Answer: B

3. At multi-server scale, which mechanism replaces Java's synchronized keyword for preventing double booking?

   • A) Thread pools with fixed queue size.
   • B) Distributed lock via Redis SETNX (or DB optimistic locking with CAS).
   • C) Read replicas for the seat table.
     Answer: B

---