Design a hotel room availability service for a travel marketplace similar to Expedia. The key requirement is low-latency availability reads. Users should be able to search for hotels and see available rooms quickly, but the system must also avoid showing rooms that are no longer available when the user tries to book. External hotel supplier APIs may be slower than the marketplace's latency target and may change availability independently. ### Constraints & Assumptions - The marketplace aggregates inventory from many hotel chains and suppliers. - Search traffic is much higher than booking traffic. - Supplier APIs have variable latency and reliability. - Availability can change outside the marketplace. - A stale search result is tolerable only if the booking flow confirms availability before payment. - The system should support popular cities, date ranges, room types, and cancellation/refund policies. ### Clarifying Questions to Ask - What are the target p95 latencies for search and booking confirmation? - Do we own any pre-negotiated inventory, or is all inventory fetched from suppliers on demand? - How fresh must displayed availability be? - What happens if a supplier confirms availability but payment fails? - Do we need global traffic, multi-currency pricing, or loyalty integrations? - Are overbooking and temporary holds allowed by supplier contracts? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How would you handle a supplier API outage during checkout? - How would you decide TTLs for availability cache entries? - How would you prevent two users from booking the last room? - How would you monitor stale availability and failed confirmations? - How would the design change for last-minute bookings in high-demand cities?