Katkat
Back

Design Room-Level Hotel Reservations Without Double Booking

Lead BankSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This problem tests the ability to design a distributed reservation system that ensures strong consistency for inventory management while handling high-concurrency read operations.

System Design: Room-Level Hotel Reservation

Design a hotel reservation system that allows users to search for room availability and book specific rooms. You must ensure that no two users can book the same room for the same date range, even under high concurrent load.

Requirements

  • Functional: Users can search for availability by date range and hotel. Users can reserve a specific room. Reservations must be atomic.
  • Non-functional: The system must strictly prevent double-booking. Search results can be slightly stale (eventual consistency for availability views is acceptable), but the booking action must be strictly consistent.
  • Scale: High volume of read searches (100k+ per second); moderate volume of booking transactions (1k per second).

Your Design Should Cover:

  1. API Design: Define the endpoints for searching rooms and creating a reservation.
  2. Data Model: Choose a database schema that efficiently checks for overlapping date ranges (e.g., start_date to end_date).
  3. Concurrency Control: Explain how you prevent double-booking when two users attempt to book the same room simultaneously.
  4. Failure Handling: Describe how to handle scenarios where a user reserves a room but the payment service fails.
  5. High Availability: How do you keep the search functionality responsive even if the reservation service experiences high latency?

Hints

Hint 1

Consider using a database with 'SELECT FOR UPDATE' or optimistic locking on a version column to handle concurrent booking attempts.

Hint 2

For the date overlap constraint, you can store bookings as half-open intervals `[start, end)` and use a database index or a specialized data structure like an interval tree.

Hint 3

Implement a two-phase process: a temporary 'hold' (with a TTL) followed by a final confirmation once payment is processed.

Follow-up questions

  • How would your design change if you needed to support 'bulk' bookings for a group of 50 rooms at once?
  • If the database becomes a bottleneck during peak search hours, what caching strategy would you implement, and how would you handle cache invalidation?
  • How do you handle reconciliation between the booking system and the hotel's physical check-in system if the network between them is unreliable?