Hotel Booking System

Design a hotel booking product integrated with external hotel inventory. The key evaluation point is consistency: search and booking depend on third-party room availability that can change outside Rippling's system. Requirements Users search for hotels by location, date range, room count, and hotel/room filters; one interviewer pushed toward latitude/longitude rather than vague city or zip inputs. Model hotels, rooms, room attributes, availability, and booking state. Ingest hotel inventory from large chains, smaller hotels, or third-party APIs; Rippling does not necessarily own the source-of-truth room inventory. Pull or call external hotel APIs to fetch and confirm room availability. Support search, room selection, and booking confirmation. Handle concurrent competition for the same room from external systems. Discuss indexes for location and availability queries. Include a consistency plan for every booking step, especially external availability checks. Notes The central trade-off is local cached availability versus just-in-time external confirmation. Cached availability gives fast search but risks double-booking; just-in-time external check is correct but slow and vulnerable to upstream outages. The canonical compromise is cache-for-search plus confirm-on-book. Room state machine is the standard reservation pattern: available → reserved (TTL) → booked with automatic expiry returning to available. The reserved state can be enforced either with an explicit expires_at column checked in short transactions, or with a distributed lock (Redis SET NX PX keyed by room_id) that auto-expires — the lock variant avoids application-level cron jobs for releasing stale holds. For the upstream booking call, use an idempotency key tied to the booking row's id so retries after timeouts don't create duplicate confirmations. The pattern is: write the booking row in pending state with a generated booking_id, call the external API with booking_id as the idempotency key, then update to confirmed or failed based on the response (or after reconciliation if the response is lost). For extremely high-contention rooms (e.g., a single luxury suite during peak season), a virtual waiting queue (Redis-backed, admit N users at a time to the booking page) prevents thundering-herd lock contention and gives a better UX than failing reservations. Some interviewers challenge entity attributes and relationship details heavily; write the schema early (Hotel, Room, RoomType, Availability, Reservation, Booking) and keep it concrete. Search design needs an explicit storage choice: the primary database is useful for transactional booking state, while an Elasticsearch-style index is better for location/date/filter search. Keep the index eventually consistent with the source-of-truth inventory and re-confirm availability before reservation. Reservation flow can be synchronous for the user-facing hold/confirmation path, but external provider calls and ingestion updates need async retry, reconciliation, and stale-cache handling. Preparation Practice a booking-state machine: searched, selected, held, confirmed, failed, expired. Be ready to explain the transition triggers and the cleanup path for each terminal state. Prepare location indexing options such as geohash, S2 cells, or lat/lon bounding boxes; default answer: geohash prefix for coarse buckets, then in-memory distance filter for the precise radius query. Drill the distributed-lock-with-TTL pattern in Redis (SET key value NX PX 600000) plus the safe-release Lua script (compare-and-delete) so concurrent holds on the same room are rejected cleanly. Rehearse external consistency patterns end-to-end: hold tokens, idempotency keys, retry queues with exponential backoff, dead-letter handling, and a periodic reconciliation job that compares local pending bookings against upstream state.