# Design Caching for a Hotel Booking System Design a hotel booking system with an explicit caching strategy. Distinguish searchable hotel content and derived availability from the authoritative reservation and inventory path, and prevent stale cache data from creating an invalid booking. ### Constraints & Assumptions - Search may tolerate bounded staleness; confirmed inventory and reservations require stronger correctness. - A room-night or inventory unit cannot be sold beyond the stated allocation rule. - Prices and policies may change between search and confirmation. ### Clarifying Questions to Ask - Is inventory modeled per room, room type, or pooled allocation? - Can temporary holds be created, and when do they expire? - Which search fields and prices may be cached, and for how long? ```hint Cache discovery, verify commitment Use caches to find options quickly, then revalidate price and inventory inside the authoritative booking transaction. ``` ### What a Strong Answer Covers - Search, detail, hold, confirm, cancel, and idempotency contracts. - Inventory and reservation data model with concurrency control. - Cache layers, keys, TTLs, invalidation, and stale-display behavior. - Payment boundary, retries, oversell prevention, recovery, and observability. ### Follow-up Questions 1. How would a flash sale or regional outage change the cache policy? 2. How would cancellation restore inventory without double crediting it?