Airline Management System

Flight Operations & Booking Platform

Design the booking side of an airline: search flights, hold a seat while the passenger pays, confirm, cancel under a fare rule, check in, and board by group, with a seat never sold twice.

Overview

An airline system sells seats on scheduled flights and then moves each passenger through check-in and boarding. A flight has a number, a route, a departure time and a seat map; each seat belongs to a cabin (first, business or economy). A booking ties one passenger to one seat on one flight and moves through a fixed set of states until the passenger boards or the booking is canceled.

The problem is broad, so the interviewer is testing scope as much as code. Pick the booking core and say what you leave out (crew, aircraft maintenance, loyalty points). Then show three things: a seat is never given to two people even when many buyers click at once; a seat held during payment comes back if the payment never finishes; and the flight and the booking each follow a state machine, so an impossible step (boarding a canceled booking, landing a flight that never left) is refused.

A strong answer scopes in two minutes, draws the two state machines, puts the lock around the seat check, and ends with a demo that covers a race, an expired hold and a refund.

Scoping the problem

Which part: booking, operations (crew, aircraft), or both? — The whole airline is too big for an hour — Booking, check-in, boarding
One flight per booking, or multi-leg trips? — Multi-leg needs all-or-nothing holds — One flight; multi-leg is a follow-up
Is a seat held while the passenger pays? — Adds a hold with a time limit — Yes, for a few minutes
How are refunds decided? — Fare rules change often: a Strategy — By the fare bought
Is overbooking in scope? — Changes the seat inventory model — Discuss, not code
Who is told about delays and cancellations? — Adds notifications — Every passenger booked on the flight
Many sales channels at once? — Decides the locking — Yes; a seat must never be sold twice

Two state machines

Both the booking and the flight keep their allowed moves in a table (BOOKING_MOVES, FLIGHT_MOVES), and one move function refuses anything not in it.

scheduled — delayed, boarding, canceled
delayed — delayed (a new time), boarding, canceled
boarding — departed, delayed
departed — arrived
arrived, canceled — nothing

Holding a seat while the passenger pays

Payment can take minutes and can fail, so the seat is held first and confirmed after. The hold carries an expiry time; the code does not run a timer to clean it up. Instead, Booking.live(now) says whether a hold still owns its seat, and the next buyer simply takes a seat whose hold has run out.

Lazy expiry (the code): check hold_until when someone wants the seat — At the next request for that seat — Nothing to run
A sweeper job every minute — Within a minute — A background job
A cache key with a time to live — When the key expires — An extra store to keep in sync

Boarding by group

The boarding group comes from the cabin through a table, BOARDING_GROUP: first is 1, business 2, economy 3. The gate calls groups in order; board refuses a passenger whose group has not been called yet. Changing the order (for example, families first) is a data change.

What you will be able to do

Scope an airline system to its booking core and say what you leave out.
Draw the booking and flight state machines and enforce them with one transition table each.
Hold a seat during payment with an expiry, and explain lazy expiry against a sweeper.
Keep the lock around the seat check, not around the payment, and prove it with a race.
Put refund rules behind a Strategy and notify passengers through an Observer.

Functional requirements

search(origin, destination, cabin, now) returns flights still selling, with their free seats in that cabin
hold(passenger, flight, seat, fare, rule, now) takes a free seat for a limited time and returns a booking reference
confirm(pnr, now) turns a live hold into a booking after payment; an expired hold is refused
cancel(pnr, now) frees the seat and returns the refund the fare rule allows (nothing for an unpaid hold)
check_in(pnr, gate) issues a boarding pass with a boarding group from the cabin
board(pnr, group_called) boards a checked-in passenger once the flight is boarding and the group is called
Flight status changes follow a transition table and notify every passenger booked on the flight

Non-functional requirements

A seat is never held or sold to two passengers at once
The lock covers the seat check only, never a payment call
Abandoned holds free their seats without a background job
Refund rules and boarding order change without editing the Airline class
Deterministic: time is passed in, so expiry and refunds are exact in tests

Interview questions

Two agents sell seat 1A at the same moment. How do you stop a double sale, in memory and in a database?
The flight is canceled. What happens to its passengers?
How would you support overbooking?
Where do times and time zones fit in?