How Would You Design a Hotel Booking System?
Learn how to design a hotel booking system with per-night inventory, atomic date-range holds, and overbooking policy for interviews.
Expected Interview Answer
A hotel booking system is designed around a date-ranged inventory model where each room type’s availability is tracked per night, reservations acquire a short-lived hold across the requested date range before payment, and a strongly consistent commit step converts the hold into a confirmed booking to prevent overbooking the same room-night.
Unlike a simple item counter, hotel inventory must be tracked per room-type-per-night, since a room available on Monday might be booked Tuesday through Thursday and free again Friday — the system typically models this with a range-aware availability table or a bitset per room per date range. When a guest searches, the query intersects requested date ranges against available inventory across all nights in the stay, returning only room types with capacity for every night requested. Booking a stay acquires a hold across all those nights atomically (all-or-nothing, since a guest cannot be given three of four requested nights); this uses a database transaction or a distributed lock spanning the date range to prevent two guests from being confirmed for the same room-night. Overbooking policies (common in the hotel industry to offset no-shows) are handled by explicitly allowing inventory to exceed physical capacity by a configured buffer, tracked and reconciled by a separate yield-management process rather than baked into the core booking transaction.
- Per-room-type-per-night inventory correctly models multi-night stays instead of a single stock counter
- All-or-nothing holds across a date range prevent partial bookings and double-selling any single night
- Separating yield-management overbooking policy from the core transaction keeps booking logic simple and auditable
- Range-aware availability queries let search return accurate results across arbitrary check-in/check-out dates
AI Mentor Explanation
Designing hotel booking is like managing a ground’s multi-day Test match seating chart where a block of seats might be sold for days one and two but free again on day four, so availability must be tracked per seat per day rather than as one simple total. When a group wants seats for all five days, the booking office checks every single day in that range and only confirms if every day has capacity, never handing out seats for three days and leaving them stranded on the fourth. The hold across all five days is placed atomically, so no other group can grab a conflicting day mid-transaction. That per-day, all-or-nothing reservation model is exactly how hotel booking manages room-night inventory.
Step-by-Step Explanation
Step 1
Model inventory per room-type-per-night
Availability is tracked as a range-aware table (or per-date bitset) so a stay spanning multiple nights can be checked and held correctly.
Step 2
Search intersects availability across the full date range
A query for check-in to check-out only returns room types that have capacity on every single night requested, not just the first.
Step 3
Acquire an all-or-nothing hold across the stay
Booking places a short-lived hold spanning every night atomically, so a guest is never given part of the requested stay.
Step 4
Confirm on payment, release on failure or timeout
Successful payment converts the hold into a confirmed booking; failure or an expired hold releases every night back into availability.
What Interviewer Expects
- Models inventory per room-type-per-night rather than a single stock counter, recognizing multi-night stays
- Ensures date-range holds/bookings are atomic (all nights or none)
- Separates overbooking/yield-management policy from the core booking transaction
- Handles search correctly by intersecting availability across the full requested date range
Common Mistakes
- Treating room inventory as a single counter that ignores which specific nights are booked
- Allowing partial bookings where some nights of a stay succeed and others silently fail
- Baking overbooking/no-show buffers directly into the core transactional booking logic instead of a separate policy layer
- Not handling the race condition where two guests both try to book overlapping nights on the same room simultaneously
Best Answer (HR Friendly)
“I would design hotel booking so availability is tracked night by night per room type, not as one overall counter, since a room can be booked some nights and free on others. When a guest requests a multi-night stay, we check every single night in that range and only confirm the booking if the whole stay is available — never giving someone part of their trip and leaving gaps. The hold across all those nights happens as one atomic step so two guests can never both be confirmed for the same room on the same night.”
Code Example
inventory:
room_type: "deluxe-king"
hotel_id: "htl_204"
availability_by_date:
"2026-08-10": 3
"2026-08-11": 2
"2026-08-12": 0 # sold out this night
"2026-08-13": 4
booking_request:
check_in: "2026-08-10"
check_out: "2026-08-13"
room_type: "deluxe-king"
hold_ttl_seconds: 900
flow:
- step: "check every night in [check_in, check_out)"
rule: "all nights must have availability > 0, else reject entire request"
- step: "acquire hold"
rule: "atomically decrement available count for every night, or roll back all if any fails"
- step: "await payment"
on_success: "convert hold to confirmed booking, decrement permanently"
on_failure_or_timeout: "release hold, restore availability for every held night"Follow-up Questions
- How would you model availability efficiently for a hotel chain with thousands of properties and room types?
- How would you implement configurable overbooking to offset predictable no-show rates?
- What happens if two guests request overlapping but not identical date ranges for the last room simultaneously?
- How would you handle a mid-stay date change (guest wants to extend by two nights) without breaking consistency?
MCQ Practice
1. Why must hotel inventory be tracked per room-type-per-night instead of a single stock counter?
A multi-night stay requires checking and holding availability independently for each night, since a room’s status can differ night to night.
2. Why must a hold across a multi-night stay be acquired atomically (all-or-nothing)?
If only some nights of a stay were held successfully, the guest could end up with gaps in their reservation, so the hold must succeed or fail as a whole.
3. Where should overbooking policy (allowing bookings beyond physical room count to offset no-shows) typically live?
Overbooking is a business/yield-management policy best kept separate from core transactional booking logic, which should remain simple and auditable.
Flash Cards
Why track inventory per room-type-per-night? — Because a room can be booked on some nights of a stay and free on others.
Why must a multi-night hold be all-or-nothing? — To prevent a guest from being confirmed for only part of their requested date range.
Where does overbooking policy belong? — In a separate yield-management layer, not baked into the core booking transaction.
What must a search query intersect? — Availability across every single night between check-in and check-out, not just the first night.