#18 Inventory/Consistency
Hotel Booking System
Let many people search and book hotel rooms at once without ever selling the same room night twice.
What is being asked
Design a hotel booking system. Search is frequent and can be slightly stale; booking is rare by comparison and must be exactly right.
Requirements
Functional
- Search hotels by place and dates with prices and availability.
- Reserve, pay, confirm, cancel.
- Hotels manage room types, rates and inventory.
Non-functional
- No overbooking beyond what the hotel allows.
- Search is read-heavy and must be fast.
- Booking must be consistent, and resilient to payment failures.
Design
- Inventory is stored per hotel, room type and date: total rooms and rooms reserved.
- Search reads from an index and cache that are updated from inventory changes. It may be seconds old.
- Booking runs a transaction that, for every night of the stay, increases reserved rooms only if it stays within the total. If any night fails the whole booking fails.
- The booking is created as pending with an expiry, the customer pays, and the booking is confirmed. If payment fails or times out, the hold is released.
Key decisions and trade-offs
- Split search from booking. They have opposite needs; forcing search to be perfectly fresh would make it slow.
- Preventing double booking. A conditional update (
reserved + 1 <= total) or optimistic locking with a version column lets the database arbitrate. Row locks also work but hold connections longer. - Hold then pay. A short reservation hold gives a fair checkout. Too long a hold blocks rooms; too short frustrates customers.
- Idempotency. A retried "book" request with the same key must return the same booking, not create a second.
Follow-up questions
- How would you support deliberate overbooking of 5%?
- What happens if payment succeeds but the confirmation step crashes?
- How do you keep the search cache correct during a flash sale?
- How would the design change for a single famous hotel with huge demand?