๐ŸŽ“ A1Learner
๐Ÿ”
0 of 64 lessons completed

Design a Flight Booking System

A flight booking system searches flights, holds seats and books seats after payment. One seat on one flight can be sold only once.

The ask

A traveller searches by route and date, picks flights and pays. The booking covers one trip, which can span more than one flight.

A seat belongs to one flight on one date. The same seat can sell again on another date, and never twice on the same flight.

Seats sit in fare groups with different prices and rules. A fare group is a set of seats on one flight sold at one price under one set of change rules.

A hold sets seats aside while payment runs. A booking is final only when every flight in the trip is held and paid.

Estimate the scale

Searches run at 10,000,000 a day. 10,000,000 / 86,400 = 116 searches per second.

Bookings run at 100,000 a day. 100,000 / 86,400 = about 1 booking per second.

Searches dwarf bookings again. 10,000,000 / 100,000 = 100 searches for each booking.

One flight carries 200 seats. 100,000 / 200 = 500 flights filled at that size match one day of bookings.

Writes are rare and precious. Search is the scale problem and booking is the trust problem.

API and data

The operations are search flights, hold seats, confirm a booking, cancel a booking and read a booking.

A search carries origin, destination, dates and traveller counts. Results carry times, stops, fare group and a full trip price.

A hold carries the flights, the fare group, the travellers and a unique booking reference. The reference makes retries safe.

A booking record stores travellers, flights, seats, fare groups, price and state. States run from held to booked to cancelled or flown.

Seat maps live per flight. A seat record shows free, held or sold, with the booking reference when it is taken.

High-level design

Search reads a flight index fed by airline schedules and live seat counts. The index is built for fast route and date reads.

A booking service owns holds and seat records. It is the only writer for seats on a flight.

The payment system collects payment after a hold. A confirmed payment turns the hold into a booking and triggers seat assignment.

Many airlines feed one search view. Each airline keeps its own booking store, and the booking service speaks to each in its own shape.

Change notices for delays and schedule moves fan out from the booking records. Only booked travellers are notified.

Deep dive: one seat sold once

Two travellers can hold for the last seat on one flight at the same moment. Search showed it free to both.

The booking service grants a seat hold as one guarded step per flight. Check and hold are written together on the flight record.

Seats are partitioned by flight, so one flight has one writer path. A busy route spreads across many flights and many writers.

The losing traveller gets other flights or fare groups at once. A paid booking for a gone seat never happens.

Expired holds free their seats. A background worker releases them and the search index updates.

Deep dive: a trip with more than one flight

A connecting trip needs seats on every flight in the trip. One full flight breaks the whole trip.

Holds are taken flight by flight as a saga. Each hold has a compensating action that releases it.

If a later flight cannot hold, earlier holds are released. The traveller picks another trip instead of owning half a trip.

Payment runs only after every hold succeeds. Money never moves for a trip that cannot fly.

Each flight leg keeps its own state inside one booking. A later change can then touch one leg at a time.

Prices that move

Prices change as seats sell and dates near. A search price is a quote with a short life, not a promise.

The hold fixes the price for the payment window. The traveller pays the held price even when the live price moves.

When a quote expires before a hold, the traveller sees the new price before paying. No silent change reaches payment.

Fare group counts drive the price steps. The pricing rule itself is an airline input to the design, not a part the design invents.

Failures and retries

An airline store can fail mid-hold across a multi-airline trip. The saga releases finished holds and the booking stays unpaid.

A payment retry uses the same booking reference. The stored result returns and seats are never held in duplicate for one retry.

A schedule change after booking moves travellers by rule. Affected bookings are found by flight, and notices go out from the booking store.

Reconciliation with each airline runs daily. Seat counts that disagree become cases for people.

Evaluation and trade-offs

A central search view buys easy comparison. Its cost is constant feeding from many airline stores.

Per-flight writers buy certainty on seats. A single very hot flight feels the one-writer limit most.

Holds buy payment safety. Their cost is seats sitting unsold inside a hold that may never pay.

The promise stays simple through every trade. A booked seat is a real seat, on a real flight, exactly once.

Scale at a glance

MeasureValue
Searches a day10,000,000
Searches per second116
Bookings a day100,000
Seats on one flight200

Exercise

Why does a booking hold seats before payment completes?