Katkat
Back

Object-Oriented Design: Hotel Room Booking System

AppleSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Tests object-oriented domain modeling, interval-overlap availability logic, and concurrency control strategies to prevent double bookings in a hotel reservation system.

Scenario

Design the core engine and object-oriented architecture for a Hotel Room Booking System. The system manages properties, room inventories across different categories, and reservations made by guests while ensuring data consistency under concurrent traffic.

Requirements

Functional Requirements

  • Property & Room Management: Support multiple hotels with rooms categorized by type (e.g., Standard, Deluxe, Suite), capacity, and base price.
  • Search & Availability: Allow guests to query available rooms in a specific hotel or city for a given date range [check_in, check_out).
  • Reservation Management: Enable guests to book an available room, view existing reservations, and cancel a reservation.
  • Dynamic Pricing / Status: Support marking rooms as maintenance/out-of-order and applying custom pricing rules based on dates.

Non-Functional Requirements

  • Strong Consistency: Zero tolerance for double-booking the same room for overlapping dates.
  • Low Latency: Fast availability lookups even with high catalog read volume.
  • High Concurrency: Safely handle hundreds of simultaneous attempts to book the same room or room type during flash sales.

Scale Assumptions

  • A hotel chain with 5,000 properties worldwide.
  • Average of 200 rooms per property (1,000,000 total rooms).
  • 10,000 search queries per second (QPS) globally; peak booking rate of 500 reservations per second.

Key Deliverables

  1. Object-Oriented Class Design: Define the primary entities, their relationships, and interface contracts (e.g., Hotel, Room, RoomType, Reservation, BookingService, AvailabilityService).
  2. Date Overlap & Availability Logic: Detail the data structures and algorithms used to represent and query room availability across date intervals.
  3. Concurrency & Race Conditions: Explain how your design prevents race conditions when two users book the same room at the same millisecond. Contrast optimistic locking, pessimistic locking, and distributed lock approaches.
  4. Database Schema: Outline the persistence model (relational or document) supporting these entities and transactional guarantees.

Hints

Hint 1

Decompose the problem by separating physical rooms from fungible inventory types, reserving specific physical room instances only when necessary.

Hint 2

Two half-open date intervals [start1, end1) and [start2, end2) overlap if and only if max(start1, start2) < min(end1, end2).

Hint 3

To prevent double-booking without bottle-necking your entire database, use database-level unique constraints or optimistic concurrency control with a version column on daily room inventory rows.

Follow-up questions

  • How would you implement a 10-minute temporary inventory hold while a guest completes the checkout/payment process?
  • If customers book room types (e.g., 'Deluxe King') rather than specific room numbers, how would you design the inventory allocation and assignment algorithm?
  • How would you scale availability search queries using a cache layer (e.g., Redis bitfields or sets) without serving stale availability data?