Design an Expedia-Style Hotel Reservation System

Design an aggregator-style hotel reservation system (Expedia-like) that resells rooms from many hotel-group APIs. The pivotal requirement is low-latency room availability without serving stale inventory — forcing an explicit cache-vs-consistency trade-off. Requirements Design a hotel reservation system similar to Expedia — an aggregator that resells rooms sourced from many hotel groups' own systems/APIs (e.g. Marriott), rather than a single chain's first-party system. Users search and book hotel rooms across many providers. Hard requirement: room-availability latency must be very low. Availability must stay correct: a room shown as available must (as much as possible) still be bookable when the user commits. Notes The central tension is cache vs. consistency. Pre-fetching and caching each hotel group's availability gives low read latency, but a provider may sell a room out-of-band immediately after you cached it — so a confirm step against the provider can fail or be slow. Calling the provider live on every read keeps inventory fresh but blows the latency budget. The interview is really about how you resolve this, not about drawing every box. One workable direction discussed: aggregators commonly pre-negotiate and lock a block of rooms from each hotel group (often at a discounted rate), so reads serve from your own cache/DB quickly; when the locked block is exhausted, fall back to calling the provider API (or lock another block). Distinguish a fast, possibly-stale availability read from an authoritative confirm-at-booking step. This was a single design round; treat it as a discussion of inventory caching, staleness windows, and the read-vs-confirm split rather than a fully specified spec. Preparation Practice articulating the aggregator caching model: a low-latency availability read backed by pre-locked inventory or short-TTL cache, plus an authoritative booking-time confirmation against the provider. Be ready to reason about staleness: TTLs, write-through/invalidation on bookings you own, and what happens when a cached room is gone at confirm time (graceful fallback, re-search).