## Design a Hotel Search and Reservation System Design a hotel system with APIs, database schema, and query paths for property discovery, date-range availability, pricing, reservation, cancellation, and booking lookup. Clarify whether room inventory is tracked by exact room or room type and whether payment is in scope. ### Part 1 — Define the Booking Contract and Schema Specify hotel, room type, inventory date, rate plan, quote, reservation, guest, and idempotency records plus public and administrative APIs. #### What This Part Should Cover - Stable property and room-type identity. - Check-in and check-out date boundary semantics. - Versioned price quote and reservation lifecycle. - Personal-data boundaries and authorization for booking lookup. ```hint Model each night explicitly A multi-night stay consumes availability for each included night, while the checkout date normally does not consume another night. ``` ### Part 2 — Query Hotels and Availability Design location and attribute search, date-range filtering, availability aggregation, sorting, pagination, and caching. Explain which queries use the search index and which must confirm authoritative inventory. #### What This Part Should Cover - Search projection for geography and hotel attributes. - Product-date or room-type-date inventory access paths. - Early rejection using minimum availability with exact verification before booking. - Stable cursor ordering and explicit price or availability freshness. ```hint Separate discovery from commitment A fast search result may be slightly stale, but the reservation transaction must recheck every required night. ``` ### Part 3 — Reserve Without Overselling Walk through quote, hold if required, booking, payment boundary, cancellation, retry, and concurrent requests for the final room. #### What This Part Should Cover - Atomic conditional decrement across all stay dates. - Caller-scoped idempotency and normalized request hash. - Expiring hold or direct-confirmation semantics. - Compensation or reconciliation when payment and booking cross systems. ```hint Make all nights win together Decrementing nights one at a time can leave partial inventory consumption when the last night is unavailable. ``` ### Part 4 — Scale and Operate Address partitioning, hot destinations, inventory updates, cache invalidation, overbooking policy, failure recovery, audit, and metrics. #### What This Part Should Cover - An authoritative partition and transaction boundary for one stay. - Durable events for search, cache, email, and analytics projections. - Reconciliation of inventory, reservations, holds, and payment outcomes. - Metrics for search latency, stale offers, conflicts, oversell prevention, and abandoned holds. ```hint Keep a reservation ledger Current availability is fast to query, but immutable booking and adjustment evidence is needed to explain and repair a mismatch. ``` ### What a Strong Answer Covers - Defines date, quote, inventory, and reservation semantics precisely. - Uses different read paths for broad discovery and authoritative commitment. - Prevents overselling across every night of a stay and handles retries safely. - Includes privacy, cache freshness, reconciliation, and customer-visible failure behavior. ### Follow-up Questions 1. How would you query availability for a flexible date window? 2. What happens when the quoted price expires during payment? 3. How would hotel staff take rooms out of service without corrupting bookings? 4. How would you migrate inventory partitions for a very large property?