Airline Booking / Seat Selection System

Core classes

class Flight { String flightNumber; Airport origin, destination; Instant departure; List<Seat> seats; }
class FareClass { String name; double priceMultiplier; } // Economy, Premium, Business, First
class Seat { String seatNumber; FareClass fareClass; }
class Passenger { String name; String passportNumber; }
class Booking { List<Flight> legs; Map<Flight, Seat> seatAssignments; Passenger passenger; BookingStatus status; }

Reusing the seat-map and locking pattern

Seat selection and the double-booking risk here are structurally identical to Movie Ticket Booking System — seats are per-flight (not a permanent property of Seat), and selection needs the same temporary-hold-with-expiry pattern (a passenger selecting seat 14C shouldn't permanently lock it away if they abandon checkout). Recognizing this as the same underlying problem, not a new one, is worth stating explicitly in an interview — reapplying an already-designed solution is a stronger signal than re-deriving seat-locking from scratch a second time.

Extending to multi-leg itineraries

class Booking {
    List<Flight> legs; // e.g. [JFK->LHR, LHR->CDG] for a connecting itinerary
    Map<Flight, Seat> seatAssignments; // one seat assignment PER LEG — a passenger picks a different seat on each flight
}

The key design change: Booking holds a list of flights (legs), not a single Flight, and seat assignment becomes a map keyed by leg, since a passenger's seat on the first flight of a connection has nothing to do with their seat on the second. The seat-hold-and-confirm flow from a single-leg booking applies per leg independently — holding seat 14C on leg 1 and seat 22A on leg 2 are two separate hold operations, and a booking should only fully confirm once every leg's hold succeeds (an all-or-nothing multi-leg commit, conceptually similar to the atomicity concern Two-Phase Commit discusses at the distributed-systems level, just within a single booking transaction here).

Follow-up questions this topic invites — and their answers

Q: What happens if seat hold succeeds for leg 1 but fails for leg 2 (e.g. the flight fills up between requests)? A: The booking needs to roll back leg 1's hold too — a multi-leg booking should be all-or-nothing, not leaving a passenger with a confirmed seat on one leg of a trip they can't complete, which is exactly why the hold-then-confirm-all-or-release-all pattern matters more here than in the single-leg Movie Ticket case.

Q: How would FareClass pricing interact with dynamic, demand-based airline pricing? A: Similar to Hotel Reservation System's pricing discussion — priceMultiplier as a static field is a simplification; real airline pricing is highly dynamic (demand, days-to-departure, historical booking curves), which argues for a pluggable PricingStrategy rather than a fixed field, following the same Strategy pattern reasoning used throughout this course.

Q: Should seat assignment happen at booking time or be deferrable to check-in? A: Both are legitimate, different product decisions — some airlines assign seats at booking (matching this design directly), others allow booking without a specific seat and assign one at check-in (a different, simpler data model where Booking doesn't need seatAssignments until later) — worth naming as an explicit scope-clarifying question at the start of the exercise, per the Object-Oriented Design Refresher's scoping guidance.