hard general · part of Practice Questions · Senior SWE Roadmap
Requirements to clarify
- Functional: search available rooms by hotel/dates, reserve a room, pay, cancel.
- Non-functional: must never double-book a room, needs to handle spikes (popular destinations, holiday booking rushes), inventory count must stay accurate under concurrent bookings.
Core components
- Inventory model: rooms as a finite, date-ranged resource — a booking consumes availability for a specific date range, which is a harder invariant to protect than a simple counter (needs range-overlap checks).
- Concurrency control: a DB-level constraint or locking strategy (optimistic concurrency with a version/availability check, or a short-lived hold similar to the Ticket Booking pattern) ensures two concurrent bookings for the same room/dates can’t both succeed.
- Search service: a read-optimized, likely denormalized/cached view of availability, separate from the strongly-consistent booking-write path — search can tolerate slight staleness, booking cannot.
- Booking & payment flow: hold room → collect payment → confirm booking, with the hold expiring if payment isn’t completed in time.
Key tradeoffs
- Splitting the fast, eventually-consistent search path from the slow, strongly-consistent booking path is the key architectural insight — treating them as one system either makes search too slow or booking too loose.