System Design Lab›System Design Questions›Design Hotel Reservation System
Design Hotel Reservation System
EasyE-commercebookinginventorytransactionsconcurrency
Question Overview
Design a hotel booking system where travelers reserve a room type for a range of dates. Booking volume is only a few requests per second, so the real challenge is correctness: no double booking under concurrency, controlled overbooking, and idempotent reservations that survive retries.…
Sign up to see the full question and AI interviewer
Requirements
- Browse hotels, room types, and nightly prices; check availability for a room type and date range
- Reserve rooms of a type for a date range, atomically across every night of the stay
- Hold inventory for up to 15 minutes while payment completes, then confirm or release it
- Never exceed physical inventory plus the hotel's configured overbooking allowance
- Idempotent booking: retries and double clicks produce exactly one reservation and one charge
- Cancellation returns every night to inventory; browsing availability may be slightly stale
Back-of-the-envelope numbers
- Bookings: 2M rooms × 70% occupancy = 1.4M occupied room-nights/day ÷ 3 nights per stay ≈ 467K reservations/day
- Booking QPS: 467K ÷ 86,400 s ≈ 5.4/s average; even a 10× holiday spike is ~54/s, easy for one relational primary
- Availability checks: 467K × 100 ≈ 47M/day ÷ 86,400 s ≈ 540/s average, ~1.6K/s at 3× peak
- Inventory rows: 20K hotels × 10 room types × 365 days = 73M rows × ~50 bytes ≈ 3.7 GB
- Reservations: 467K/day × ~1 KB ≈ 470 MB/day ≈ 170 GB/year, a small relational dataset
- Write amplification: a 3-night stay updates 3 inventory rows in one transaction; contention concentrates on last rooms for peak dates
Key components
- Room-type inventory table with one row per (hotel_id, room_type_id, date) holding total_rooms and total_reserved
- Booking transaction: conditionally increment total_reserved for every night, only if it stays within total_rooms plus the allowance; roll back if any night fails
- Reservation service using a client-generated idempotency key under a unique constraint, with states pending, confirmed, canceled, and expired
- Payment outside the DB transaction: authorize against a pending hold, capture on confirmation, and let an expiry job release unpaid holds after 15 minutes
- Availability cache or search index updated from inventory changes, used for browsing only and never for the final booking decision
- Relational primary with read replicas, sharded by hotel_id only if needed so every booking remains a single-shard transaction
- Hotel catalog, photos, and rates served from cache and a CDN because they change rarely
Common mistakes
- Reading availability and then inserting the reservation without a lock or conditional update, letting two travelers book the last room
- Tracking inventory by physical room number at booking time; guests book a room type and rooms are assigned at check-in
- Holding a database transaction or row lock open while waiting on the payment gateway
- Omitting an idempotency key, so a double click or client retry creates two reservations and two charges
- Reaching for distributed locks, sharding, and microservices at ~5 bookings/s when one ACID database handles it
- Trusting cached availability for the final decision instead of re-checking inside the booking transaction
Likely follow-ups
- What happens if a traveler's payment succeeds just after their 15-minute hold has expired?
- How would you keep inventory in sync with third-party channels such as online travel agencies that sell the same rooms?
- How would you let a guest change their dates atomically without risking losing the original booking?
- How would the design change for a flash sale where 10,000 people try to book 50 discounted rooms at once?
- How would you shard inventory if the platform grew to 1M hotels?
- How would you make a city-wide search for available hotels under a price limit fast?
No community solutions yet
Be the first to publish your solution
Practice ‘Design Hotel Reservation System’ with an AI Interviewer
Get scored feedback on your diagram, scalability approach, and trade-offs. Free while we grow — up to 3 full interviews a day.