Hotel, Room, Booking classes in LLD - System Design Guide

Problem Statement

When designing a hotel booking system, mixing responsibilities of hotels, rooms, and bookings in a single class leads to code that is hard to maintain and extend. This causes bugs when adding features like checking room availability or managing multiple bookings per room.

Solution

Separate the system into three classes: Hotel, Room, and Booking. Hotel manages rooms, Room represents individual rooms with their details, and Booking handles reservation data. This clear division allows each class to focus on its own responsibility, making the system easier to understand and modify.

Architecture

┌─────────┐       1..*       ┌────────┐       0..*       ┌─────────┐
│  Hotel  │──────────────────▶│  Room  │──────────────────▶│ Booking │
└─────────┘                   └────────┘                   └─────────┘

This diagram shows that one Hotel has many Rooms, and each Room can have multiple Bookings.

Trade-offs

✓ Pros

→

Clear separation of concerns improves code readability and maintainability.

→

Easier to add new features like room availability checks or booking cancellations.

→

Classes can be tested independently, improving reliability.

✗ Cons

→

Requires more initial design effort to define clear interfaces between classes.

→

May introduce complexity in managing relationships and data consistency.

→

Overhead of creating and managing multiple objects instead of a single class.

Use when building any hotel booking system that needs to handle multiple rooms and bookings with clear responsibilities and future feature expansion.

Avoid if the system is a simple one-off script with only a few bookings and no plans for extension or maintenance.

Real World Examples

Airbnb

Separates listings (similar to hotels), individual rooms, and booking transactions to manage complex availability and pricing rules.

Booking.com

Uses distinct entities for hotels, rooms, and bookings to handle millions of reservations and dynamic room availability.

Code Example

The before code mixes room and booking logic in one class, making it hard to extend. The after code separates concerns: Hotel manages rooms, Room manages bookings and availability, and Booking represents a reservation. This makes the system clearer and easier to maintain.

LLD

### Before: All logic in one class (bad design)
class HotelSystem:
    def __init__(self):
        self.rooms = {}
        self.bookings = []

    def add_room(self, room_number, room_type):
        self.rooms[room_number] = {'type': room_type, 'booked_dates': []}

    def book_room(self, room_number, date):
        if date not in self.rooms[room_number]['booked_dates']:
            self.rooms[room_number]['booked_dates'].append(date)
            self.bookings.append({'room': room_number, 'date': date})
            return True
        return False


### After: Separate classes with clear responsibilities
class Booking:
    def __init__(self, room, date):
        self.room = room
        self.date = date

class Room:
    def __init__(self, number, room_type):
        self.number = number
        self.room_type = room_type
        self.bookings = []

    def is_available(self, date):
        return all(booking.date != date for booking in self.bookings)

    def book(self, date):
        if self.is_available(date):
            booking = Booking(self, date)
            self.bookings.append(booking)
            return booking
        return None

class Hotel:
    def __init__(self):
        self.rooms = {}

    def add_room(self, number, room_type):
        self.rooms[number] = Room(number, room_type)

    def book_room(self, number, date):
        room = self.rooms.get(number)
        if room:
            return room.book(date)
        return None

Alternatives

Monolithic Class

Combines hotel, room, and booking logic into one class without separation.

Use when: Only for very simple prototypes or scripts with minimal functionality and no future scaling.

Database-Driven Design

Focuses on database tables and relations first, then generates classes from schema.

Use when: When the system is heavily data-centric and database design drives the application structure.

Summary

Separate Hotel, Room, and Booking into distinct classes to keep responsibilities clear.

This separation improves maintainability and allows easier feature additions like availability checks.

Avoid mixing multiple concerns in one class to prevent complex, hard-to-maintain code.