This question evaluates a candidate's ability to design scalable, consistent, and resilient distributed systems for transactional domains, emphasizing API design, data modeling, concurrency control, idempotency, seat inventory guarantees, and external integrations like payments and ticketing.
Design an airline booking system that supports flight search (including multi‑leg connections), booking, seat selection, and itinerary modification/cancellation. Define core REST/gRPC APIs for search, book, modify, and cancel; the data model for flights, legs, fares, seat inventory, reservations, and users; and how to ensure seat availability, atomicity across connecting segments, and idempotency. Discuss consistency guarantees, concurrency control to prevent overbooking, and strategies for strong vs. eventual consistency across regions. Explain integration with payment, ticketing, notifications, and refund flows. Address indexing and caching for search queries (origins, destinations, dates, cabin), pagination and sorting, and flexible‑date search. Cover scaling, sharding, and read/write patterns; resiliency (failover, retries, sagas), observability, and SLAs. Compare trade‑offs for single‑airline vs. multi‑tenant OTA scenarios and outline partner API integration and rate limiting.
Quick Answer: This question evaluates a candidate's ability to design scalable, consistent, and resilient distributed systems for transactional domains, emphasizing API design, data modeling, concurrency control, idempotency, seat inventory guarantees, and external integrations like payments and ticketing.
Design an airline booking platform that lets travelers search for flights, book them, select seats, and modify or cancel their itineraries.
Walk through a coherent, end-to-end design covering the areas below. State the minimal assumptions you need to make the system concrete, and call out the trade-offs behind each major decision.
Write-critical
booking path — reservations and seat inventory must be correct.
No overselling
— seat inventory must not oversell (unless oversell is a deliberate, bounded business policy).
Constraints & Assumptions
These anchor the discussion; refine them with the interviewer as needed.
Itinerary shape:
one-way, round-trip, and multi-leg connections up to
2 stops
.
Workload asymmetry:
searches vastly outnumber bookings (low single-digit look-to-book conversion is typical), so the read and write paths have very different requirements.
Correctness over freshness on writes:
search may serve slightly stale availability, but a confirmed booking must never oversell a physical departure.
External providers:
payments, ticketing/issuance, and notification delivery are integrated third parties, not built in-house.
Currency:
assume a single currency snapped at pricing time unless you choose to handle multi-currency explicitly.
Part 1 — Functional Scope & Assumptions
Define the user-facing capabilities and the assumptions that make the design concrete:
Flight search:
one-way, round-trip, and multi-leg connections (
max 2 stops
), with cabin filters and passenger types.
Booking:
create a reservation, hold seats, take payment, and issue tickets.
Seat selection:
retrieve seat maps and assign seats per segment.
Modify / cancel:
reprice and change flights; support partial and whole cancellation, plus refunds.
Part 2 — APIs to Define
Specify the core REST and gRPC endpoints for: search, price/offer retrieval, book/confirm, modify, cancel, seat selection, and a fare calendar (flexible dates). Address idempotency for write operations.
Part 3 — Data Model to Specify
Cover: flights, legs/segments, fare classes and rules, seat inventory (by fare bucket and cabin), offers, reservations/PNR, tickets, payments, users, and refunds.
Part 4 — Guarantees & Controls (the core)
This is where most of the signal lives. Address:
Seat availability and atomicity
across connecting segments (a multi-leg booking touches several inventory units plus external payment and ticketing).
Idempotency
of booking, modify, and cancel.
Consistency guarantees
(strong vs. eventual) and
concurrency control
to prevent overbooking.
Multi-region strategy:
how strong vs. eventual consistency is handled across regions.
Part 5 — Integrations
Explain integration with payments (authorize / capture / void / refund), ticketing issuance, and notifications.
Part 6 — Search: Indexing, Caching, Pagination, Flexible Dates
Address indexing and caching for queries by origin, destination, dates, and cabin; pagination and sorting; and flexible-date (fare-calendar) search.
Part 7 — Modify, Cancel, Refund
Reprice and change flights; support partial and whole cancellation. Distinguish voluntary vs. involuntary changes, apply fare rules and penalties, and handle refunds.
Part 8 — Scale, Sharding & Resilience
Cover scaling, sharding, and read/write patterns; resiliency (failover, retries, sagas / compensations); and observability and SLAs.
Part 9 — Multi-Tenancy & Partners
Compare trade-offs for single-airline vs. multi-tenant OTA scenarios, and outline partner API integration (GDS / NDC / airline-direct) and rate limiting.
Clarifying Questions to Ask Guidance
Before designing, scope the problem with the interviewer:
Scale:
roughly how many searches/day and what look-to-book conversion? What peak-to-average ratio should I design for?
Single airline vs. OTA:
am I designing for one carrier's inventory, or aggregating many partners (GDS/NDC/direct)?
Oversell policy:
is overbooking strictly forbidden, or is controlled, bounded oversell a deliberate business lever?
Latency / freshness SLAs:
what's the target search p95, and how stale may displayed availability be before booking?
Geographic footprint:
which regions, and is low-latency
search
in-region a hard requirement while writes can route to a home region?
Payment model:
auth-then-capture, and who owns the captured-but-unticketed risk window?
What a Strong Answer Covers Premium
Follow-up Questions Guidance
Be ready to go deeper:
What breaks first at 10–100× search traffic
, and which component do you scale or redesign before the others?
A
stale search snapshot
shows a seat that's actually gone — walk through exactly what the user experiences and where the system catches it.
The
payment provider authorizes but ticketing fails
mid-saga — what's the compensation, and is the customer ever charged?
How would you support
controlled overbooking
to a bounded limit
without
reintroducing a race, and how do you monitor and auto-disable it?
A whole
region goes down
— what's your failover story for in-flight bookings and what RPO do you accept?