Airline Reservation System – Low Level Design Interview Practice
Practise the Airline Reservation System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Concurrency. The model is a booking system; the round turns on how two passengers are prevented from holding seat 14A, and on what happens to a hold that is never paid for.
Requirements to establish first
- Search flights by route and date, including itineraries with a connection.
- Show the seat map for a flight with its fare classes.
- Hold selected seats for a fixed window while payment is attempted.
- Confirm a booking on payment, and release the hold on timeout or failure.
- Cancel and refund according to the fare rules of the class booked.
Core classes
- Flight – Route and schedule. The recurring service, not one departure.
- FlightInstance – One dated departure with its own aircraft and seat inventory. Bookings attach here, not to Flight.
- Seat / SeatAssignment – A physical seat on an aircraft, and its state on one instance: free, held until T, booked.
- Booking – Passengers, seats, fare, status. Moves through pending, confirmed, cancelled.
- Payment – The transaction, kept separate so a failed payment does not corrupt a booking.
- PricingStrategy / FareRules – Class-dependent price and the cancellation terms that go with it.
Design patterns that apply
- State – Booking status is a machine with illegal transitions - a cancelled booking cannot be confirmed - and the pattern makes that structural.
- Strategy – Fare pricing and cancellation rules vary by class and route.
- Observer – Schedule changes notify every booking on that instance.
Follow-up questions to expect
- A hold expires while the payment gateway is still processing. Which wins, and how does the other one find out?
- An aircraft is swapped for a smaller one. What happens to seats that no longer exist?
- Show the lock or the compare-and-set that makes seat selection safe, and say what it costs under load.
Where candidates lose marks
- Attaching bookings to Flight rather than to a dated instance, which makes "flight full on Tuesday" inexpressible.
- Treating hold and booking as one state, so an abandoned checkout holds the seat forever.
- Claiming a database transaction solves it without saying what is locked or for how long.