Full Stack • Java • System Design • Cloud • AI Engineering

Hotel Reservation System Design - Complete Low-Level Design Guide

Design a scalable Hotel Reservation System using Java and Spring Boot. Learn requirement analysis, UML class diagrams, room inventory, booking lifecycle, pricing strategy, payment handling, concurrency control, SOLID principles, design patterns, and enterprise architecture.

Introduction

Hotel Reservation System is a popular Low-Level Design interview problem because it covers:

  • Room inventory management
  • Search and availability
  • Booking lifecycle
  • Payments
  • Cancellation
  • Refunds
  • Pricing
  • Concurrency
  • Notifications

The main challenge is to ensure that the same room is not booked by two customers for the same date range.

Problem Statement

Design a Hotel Reservation System that allows customers to:

  • Search hotels
  • View available rooms
  • Reserve rooms
  • Make payments
  • Cancel bookings
  • Receive confirmation
  • View booking history

Administrators should be able to:

  • Add hotels
  • Add rooms
  • Update room availability
  • Manage pricing
  • View reservations
  • Manage cancellations

Functional Requirements

  • Search hotels by city, date, guests, and room type
  • Check room availability
  • Reserve room
  • Confirm booking after payment
  • Cancel reservation
  • Calculate refund
  • Send notifications
  • Maintain booking history
  • Support multiple hotels
  • Support multiple room types

Non-Functional Requirements

  • Highly available
  • Scalable
  • Thread-safe
  • Secure
  • Maintainable
  • Extensible
  • Transaction-safe

High-Level Architecture

flowchart TD
    Customer --> BookingService
    BookingService --> HotelService
    BookingService --> RoomService
    BookingService --> PricingService
    BookingService --> PaymentService
    BookingService --> NotificationService
    BookingService --> Database

Core Entities

classDiagram
    class Hotel
    class Room
    class RoomType
    class Customer
    class Reservation
    class Payment
    class Invoice

    Hotel --> Room
    Room --> RoomType
    Customer --> Reservation
    Reservation --> Room
    Reservation --> Payment
    Reservation --> Invoice

Entity Responsibilities

Hotel

Stores:

  • Hotel ID
  • Name
  • Address
  • City
  • Rating
  • Amenities

Room

Stores:

  • Room Number
  • Floor
  • Room Type
  • Status
  • Price

RoomType

Examples:

  • Single
  • Double
  • Deluxe
  • Suite
  • Family

Customer

Stores:

  • Customer ID
  • Name
  • Email
  • Phone

Reservation

Stores:

  • Reservation ID
  • Customer
  • Room
  • Check-in date
  • Check-out date
  • Status

Payment

Stores:

  • Payment ID
  • Amount
  • Method
  • Status

Room Status

Available
Reserved
Occupied
Cleaning
Maintenance
Blocked

Reservation Status

Created
Pending Payment
Confirmed
Checked In
Checked Out
Cancelled
Expired

Booking Flow

sequenceDiagram
    participant Customer
    participant BookingService
    participant RoomService
    participant PaymentService
    participant NotificationService

    Customer->>BookingService: Search Room
    BookingService->>RoomService: Check Availability
    RoomService-->>BookingService: Available Rooms
    Customer->>BookingService: Reserve Room
    BookingService->>PaymentService: Process Payment
    PaymentService-->>BookingService: Payment Success
    BookingService->>NotificationService: Send Confirmation
    BookingService-->>Customer: Booking Confirmed

Availability Check

A room is available only if there is no confirmed reservation overlapping with the requested date range.

Requested:
July 10 - July 15

Existing:
July 12 - July 14

Result:
Not Available

Date Overlap Rule

Two bookings overlap when:

newCheckIn < existingCheckOut
AND
newCheckOut > existingCheckIn

This rule is critical for preventing double booking.

Room Reservation Flow

flowchart LR
    Search --> AvailableRooms
    AvailableRooms --> SelectRoom
    SelectRoom --> TemporaryHold
    TemporaryHold --> Payment
    Payment --> ConfirmedBooking

Temporary Hold

When a customer selects a room, the system may place a temporary hold.

Example:

Room 305
Hold Time: 10 minutes

If payment is not completed within the hold time, the room becomes available again.

Cancellation Flow

flowchart LR
    ConfirmedBooking --> CancelRequest
    CancelRequest --> RefundCalculation
    RefundCalculation --> PaymentRefund
    PaymentRefund --> RoomReleased
    RoomReleased --> Notification

Pricing Strategy

Hotel pricing may depend on:

  • Room type
  • Weekday or weekend
  • Season
  • Holiday
  • Demand
  • Membership level
  • Discount coupon

Design Patterns Used

Strategy Pattern

Used for pricing and cancellation rules.

Examples:

  • Standard Pricing
  • Weekend Pricing
  • Seasonal Pricing
  • Dynamic Pricing

Factory Pattern

Used to create payment methods.

Examples:

  • Credit Card
  • Debit Card
  • Wallet
  • UPI

Observer Pattern

Used for notifications.

Subscribers:

  • Email
  • SMS
  • Push Notification

State Pattern

Used for reservation lifecycle.

Created → Pending Payment → Confirmed → Checked In → Checked Out

SOLID Principles

  • ReservationService handles reservation logic only.
  • PricingService handles price calculation.
  • PaymentService handles payments.
  • NotificationService handles messages.
  • New pricing rules can be added without modifying booking logic.
  • BookingService depends on interfaces, not concrete implementations.

Concurrency Handling

Multiple customers may try to book the same room at the same time.

Possible issues:

  • Double booking
  • Duplicate payment
  • Race conditions
  • Inventory mismatch

Solutions:

  • Database transactions
  • Optimistic locking
  • Pessimistic locking
  • Distributed locks
  • Temporary holds with expiry
  • Unique constraints on room and date range where supported

Database Tables

Hotel
Room
Room_Type
Customer
Reservation
Payment
Invoice
Notification

REST APIs

GET    /hotels
GET    /hotels/{hotelId}/rooms
POST   /reservations/hold
POST   /reservations/confirm
POST   /reservations/cancel
POST   /payments
GET    /customers/{customerId}/reservations

Spring Boot Layers

flowchart LR
    Controller --> Service
    Service --> Repository
    Repository --> Database

Enterprise Architecture

flowchart TD
    WebApp --> APIGateway
    MobileApp --> APIGateway

    APIGateway --> BookingService
    BookingService --> HotelService
    BookingService --> RoomInventoryService
    BookingService --> PricingService
    BookingService --> PaymentService
    BookingService --> NotificationService

    BookingService --> PostgreSQL
    BookingService --> Redis
    BookingService --> Kafka

Redis can be used for temporary room holds.

Kafka can publish events such as:

  • ReservationCreated
  • ReservationConfirmed
  • PaymentCompleted
  • ReservationCancelled
  • RefundProcessed

Common Mistakes

❌ Not checking date overlap correctly.

❌ No temporary hold mechanism.

❌ Payment before room hold.

❌ No concurrency control.

❌ Hardcoded pricing rules.

❌ No cancellation/refund strategy.

❌ Tight coupling between booking, payment, and notification logic.

Interview Questions

  1. How do you prevent double booking?
  2. How do you check room availability for a date range?
  3. Why do we need temporary room holds?
  4. How would you implement dynamic pricing?
  5. Which design patterns are useful in this system?
  6. How do you handle payment failure?
  7. How do you support cancellation and refund?
  8. How would you scale this system for multiple cities?
  9. How would Redis help in this design?
  10. How would you design the reservation database?

Summary

A Hotel Reservation System is a strong LLD problem because it combines inventory management, date-range availability, payments, pricing, cancellation, concurrency, and notifications.

A production-ready design should include:

  • Clear domain entities
  • Room availability logic
  • Temporary holds
  • Transaction-safe booking
  • Payment integration
  • Pricing strategy
  • Cancellation and refund strategy
  • REST APIs
  • Spring Boot layered architecture
  • Redis for holds
  • Kafka for events
  • Strong concurrency control