Airline Management: One Journey, Several Carefully Kept Promises

Pune to Srinagar, via Delhi, in December

Ananya is booking a trip for herself and her father: Pune to Delhi on the morning flight, then Delhi to Srinagar for a cousin's wedding. That is two passengers and two legs. On the day, Delhi is foggy, the first flight is late, and the airline swaps the second leg's aircraft for a smaller one. (Ananya, her father, Sahyadri Air and every number here are made up for teaching.)

Farhan is the engineer behind Sahyadri Air's booking system. Each thing that happens to Ananya's trip forces one decision in his design:

The central challenge is coordinating passengers, capacity, payments and changes without losing track of what was promised. This guide covers a simplified airline business system, not aircraft control software or a full airline operations platform.

In 30 seconds, as an architect would frame it: "Inventory belongs to a dated flight instance, and it's consumed per passenger per segment. A connecting journey holds every segment atomically if they share a store, or through a saga with compensation if they don't. Payment and ticketing are separate recorded outcomes, so 'charged but not ticketed' is a visible state with reconciliation, never a reason to charge again. Operations changes such as delays, swaps and cancellations are durable events that drive search updates and rebooking workflows."

1. "I booked SA 101. Which day?": routes vs departures

A school bus may run the same route every day, but a seat on Monday's bus isn't a seat on Tuesday's. An airline system needs the same distinction:

• A flight definition is "SA 101, Pune to Delhi, 06:10 daily". It's a recurring identity.
• A flight instance is "SA 101 on 14 December". It's one dated departure, with its own capacity, timing and passengers.

Everything that can run out, such as seats, belongs to the instance.

What the first version does. Customers search dated flights, build journeys with several legs, book for several passengers, view status and request cancellation. Staff manage flight instances, aircraft assignments and disruptions. Crew see their duties.

What it deliberately leaves out: overbooking, interline settlement, loyalty pricing and automated crew optimisation. These are discussed as extensions rather than hidden inside the basic design.

The rules:

• A booking refers to dated departures, not just a flight number.
• Capacity is consumed per passenger per segment. Ananya's trip consumes four units: two people on two legs.
• One assigned seat on one departure can't belong to two active allocations.
• A multi-leg itinerary can't be labelled fully confirmed while a required leg failed.
• Payment and ticket issuance are separate recorded outcomes.
• Search may lag briefly, but booking must revalidate availability, price and restrictions.

The domain model

Ananya is booking for her father, who has no login. Don't require every passenger to have an account. Protect travel and identity details with role and ownership checks instead.

erDiagram
    ITINERARY ||--|{ PASSENGER_SEGMENT : contains
    PASSENGER ||--o{ PASSENGER_SEGMENT : travels
    FLIGHT_INSTANCE ||--o{ PASSENGER_SEGMENT : carries
    FLIGHT_DEFINITION ||--o{ FLIGHT_INSTANCE : schedules
    AIRCRAFT ||--o{ FLIGHT_INSTANCE : operates

Reading the diagram. ||--|{ means "one, to one-or-more", and ||--o{ means "one, to zero-or-more". Read the lines as sentences:

• One itinerary contains one or more passenger segments. Ananya's itinerary has four: two people, two legs.
• One passenger travels on many segments.
• One flight instance carries many passenger segments. This is where capacity is counted.
• One flight definition schedules many instances. That's SA 101, every day.
• One aircraft operates many instances. The aircraft brings the seat layout, which matters in section 5.

The diagram shows relationships only. Capacity and seat rules must be enforced in authoritative storage.