Getting Ready: Airline Management

The global airline industry generates over $800 billion in annual revenue. Every time a traveler searches for a flight, the system behind the scenes must search seat inventories across multiple fare classes, apply dynamic pricing rules, manage booking confirmations, and push real-time notifications for gate changes, delays, and cancellations. Airlines like Delta, Emirates, and United depend on reservation systems that handle millions of booking transactions daily.

From a Low Level Design perspective, the Airline Management System is a rich exercise because it combines several challenging requirements into one cohesive domain:

• Multi-class seat inventory — Economy, Business, and First Class each have different seat maps, pricing tiers, and availability rules. Managing these without rigidly coupling the booking engine to specific classes is a design challenge solved by the Strategy and Factory patterns.
• Booking lifecycle — A reservation moves through states (PENDING, CONFIRMED, CHECKED_IN, CANCELLED, COMPLETED) that mirror real-world airline operations and naturally call for state machine modeling.
• Dynamic pricing — Fare prices change based on demand, days-to-departure, and seat availability. Encapsulating these pricing algorithms is a textbook Strategy Pattern opportunity.
• Notification fan-out — Passengers, crew, and ground staff must all be notified when a flight is delayed or a gate changes. This is a classic Observer Pattern scenario.
• Complex entity relationships — Airlines operate flights that have aircraft, flights belong to routes, routes connect airports, bookings reference passengers and seat assignments — the relationship graph is far richer than simpler design problems.

Interviewers favor this problem because it tests whether a candidate can model a multi-stakeholder, state-heavy system with pluggable pricing and event-driven notifications — all within a 45-minute design session.

By completing this design problem, you will:

• Model a multi-entity domain with Airlines, Flights, Aircraft, Airports, Passengers, Bookings, and Seat assignments — practicing composition and association relationships (Fundamentals S4)
• Apply the Strategy Pattern to encapsulate multiple pricing algorithms (economy base-fare, business multiplier, first-class premium) behind a single interface (Fundamentals S12)
• Use the Factory Pattern to create seat objects for different travel classes without exposing instantiation logic (Fundamentals S10)
• Implement the Observer Pattern for flight-status notifications — delays, gate changes, cancellations broadcast to all registered observers (Fundamentals S12)
• Design a booking state machine that transitions a reservation through PENDING, CONFIRMED, CHECKED_IN, CANCELLED, and COMPLETED states
• Create Use Case, Class, and Sequence diagrams — three complementary UML views of the same system (Fundamentals S5)
• Write complete Python and Java implementations with type hints, access modifiers, and realistic driver examples
• Justify every design decision — why Strategy over hardcoded if/else for pricing, why Factory over direct constructors for seats, why Observer over polling for notifications

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition (aircraft owns seats) and Association (booking references passenger) (Fundamentals S4)
• Strategy Pattern — swapping algorithms at runtime through a common interface (Fundamentals S12)
• Observer Pattern — one-to-many notification when an object's state changes (Fundamentals S12)
• Factory Pattern — encapsulating object creation behind a factory method (Fundamentals S10)
• Enums — modeling fixed sets like seat class, booking status, and flight status (Fundamentals S3)
• UML Class Diagrams — reading and interpreting class boxes, relationship arrows, and multiplicities (Fundamentals S5)
• UML Sequence Diagrams — lifelines, activation bars, and message flow (Fundamentals S5)

If you've completed the Hotel Management System (DP14) or Movie Ticket Booking (DP19), you'll find familiar patterns here — state-driven entities, multi-class resource allocation, and booking confirmation flows. The Airline System adds richer pricing strategy and broader notification scope.

We will design: The core domain logic for an Airline Management System — airlines, flights, aircraft with seat maps, multi-class booking, fare calculation with pluggable pricing strategies, booking state management, passenger profiles, and observer-based flight-status notifications.

We will NOT design: Distributed reservation databases (like Amadeus GDS), REST API endpoints, payment gateway integration, loyalty/frequent-flyer point accumulation, baggage tracking systems, or crew scheduling algorithms. These are infrastructure or system-design concerns beyond the scope of an LLD exercise.

Key distinctions from similar problems:

• vs. Hotel Management (DP14) — Hotels have room types; airlines have fare classes with dynamic pricing. Hotels check in for nights; airlines manage flight legs with departure/arrival times.
• vs. Movie Ticket Booking (DP19) — Both book seats, but airlines have multiple fare classes per physical seat and dynamic pricing that changes based on demand curves, not just time slots.
• vs. Car Rental System (DP12) — Both manage bookable resources, but airline seats are non-transferable, tied to a specific flight at a specific time, and subject to regulatory constraints like overbooking limits.