Problem Statement: Flight Search & Booking Platform
Problem Statement: Flight Search & Booking Platform — flight search & booking interview depth
Problem Statement: Flight Search & Booking Platform
Design Google Flights / Kayak-class flight search & booking: GDS/NDC aggregation, itinerary merge, inventory holds, and ticket issuance. This section covers problem statement: flight search & booking platform in the understanding phase.
Operational detail
Quantify fan-out budgets, hold TTLs, and idempotency before naming SKUs. State AP for search caches and CP for booking/PNR rows with explicit stale-offer and double-booking stories.
Failure and edge cases
GDS timeout mid-merge, fare jump between select and pay, hold expired during checkout, airline 409 on last seat, and partial provider outage during holiday peak.
Interview checkpoints
1 public record OfferHoldToken(String offerId, long inventoryVersion, Instant expiresAt) {}
1 def fan_out_budget_ms(provider_count: int, base: int = 2200) -> int: 2 return max(800, base - 40 * provider_count)
1 export interface Itinerary { id: string; segments: Segment[]; priceCents: number; } 2 export function cheaperFirst(a: Itinerary, b: Itinerary): number { return a.priceCents - b.priceCents; }
Why interviewers care
Flight Search & Booking Engine interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.
Interview checkpoint
Name one failure story for Problem Statement: Flight Search & Booking Platform that proves you understand real outages, not happy-path diagrams.
Key Highlights
- •500+ airline and GDS sources
- •sub-3s ranked results under fan-out
- •PNR after price-locked offer
- •multi-leg graph combinatorics
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Separate search AP from booking CP in Problem Statement: Flight Search & Booking Platform."
- "Quantify fan-out QPS before Redis sizing."