Design flight search and booking (MakeMyTrip)

Live search for every request is impossible: suppliers are slow, cap our request rate, and charge or penalise high look-to-book ratios. So cache, but understand the cost of a stale price: if the user sees ₹4,500 and re-price says ₹5,200, many abandon, and trust drops. Make TTL a function of risk, not one number. Fares close to departure and on busy routes change fast, so they get 5-10 minute TTLs; fares 60+ days out change slowly and can live for hours. Learn TTLs from data: log the difference between cached price and live re-price per route and days-to-departure, and shorten TTLs where mismatches are frequent. Cache per supplier, not per full result, so one supplier's refresh does not require calling all. Use stale-while-revalidate: serve a slightly stale price immediately with a 'prices may change' hint and refresh in the background. Pre-fetch the top few hundred routes for the next 30 days during off-peak hours so popular searches are always warm. Measure two numbers continuously: cache hit ratio (cost) and price accuracy at re-price (quality); you are tuning a trade-off between them.

Booking crosses two external systems that can fail independently: the airline and the payment gateway. A database transaction cannot cover them, so use a durable workflow (Temporal or a state machine with an outbox) with explicit states: pending_payment → held → paid → ticketing → ticketed, and failure paths with compensations. Order matters. Hold the seat (create a PNR) before payment where the supplier allows it, so you do not take money for a seat that is gone. Capture payment only after the hold succeeds; some OTAs authorise first and capture after ticketing to avoid refunds. Ticketing calls are not always idempotent and can time out after succeeding at the airline. So before retrying, query the PNR status from the supplier to see whether tickets were issued; never blindly re-issue, or you may double-ticket. If ticketing truly fails, cancel the PNR and refund, and send an honest message. Every step is retried with backoff and has a timeout matching the hold expiry. A reconciliation job compares our bookings with supplier ticket reports and payment settlements daily, and flags 'paid but not ticketed' cases for urgent support action.

A single search may call 5-10 sources: two GDSs, NDC for full-service airlines, direct APIs of low-cost carriers, and sometimes consolidators. Each has different latency and reliability. The aggregator gives every call the same overall deadline (e.g. 2.5 s) and uses a per-supplier circuit breaker: if a supplier is timing out, stop calling it for 30 s and serve cached data instead of slowing every search. Streaming results over SSE improves perceived speed: the first screen shows cached and fast-supplier results in under a second. Deduplicate the same flight from multiple channels by flight number, time and fare class, preferring the cheaper channel with a better ticketing success rate. Round-trip and multi-city searches multiply combinations; cap the combinations per leg and let suppliers' own combinable fares lead. Ranking is not just cheapest: a 'best' sort mixes price, duration, stops, departure time and airline reliability, and is trained on click-to-book data from the search logs.

Holding first prevents charging for unavailable seats but some LCCs do not support holds, and holds expire. For those, take payment authorisation first, then ticket immediately and capture on success. The workflow must support both per supplier.

Short TTLs mean accurate prices but high supplier cost and slower searches. Long TTLs are cheap and fast but cause price changes at booking. Use variable TTLs by days-to-departure and route volatility, tuned from re-price mismatch data.

Temporal gives durable timers, retries and history out of the box, which suits a multi-step booking with 15-minute waits. A hand-written state machine on Postgres with an outbox works too but you rebuild timers, retries and visibility yourself.

Streaming results lowers perceived latency but the list reorders as better prices arrive. Many OTAs show a progress bar and keep the top of the list stable, inserting new cheaper results with a highlight.

Search traffic triples but supplier quotas do not. Raise cache TTLs temporarily for far dates, pre-fetch hot routes, and apply per-user rate limits to stop bots and scrapers that inflate look-to-book.

Popular route keys like DEL-BOM tomorrow are read thousands of times per second. Replicate hot keys or keep a small in-process cache in the search nodes for a few seconds.

Slow suppliers hold connections. Use async I/O, bulkheads (separate pools per supplier) and circuit breakers so one supplier cannot consume all capacity.

The workflow queries the PNR status before retrying. If ticketed, it records the ticket; if not, it retries within the hold window, then cancels and refunds automatically. The user sees 'confirming your ticket' rather than a failure page.

Its circuit breaker opens; searches use cached fares and other channels. Re-price for offers from that GDS fails cleanly and the user is offered the same flight from another channel if available.

The Idempotency-Key on POST /bookings returns the existing booking, so the user is not charged twice for a double tap.