Getting Ready: Hotel Management System

Every hotel in the world — from a 20-room roadside inn to a 3,000-room Las Vegas resort — runs on a Property Management System (PMS). Companies like Oracle Hospitality (OPERA PMS, used by over 40,000 hotels worldwide), Cloudbeds, Mews, and RoomRaccoon have built entire businesses around this domain. The global hotel management software market is projected to exceed $5 billion by 2027.

What makes this problem fascinating from a design perspective is the state management challenge. A hotel room isn't simply "available" or "occupied" — it moves through a lifecycle of states: Available → Reserved → Occupied → Under Maintenance → Available. Each transition has business rules: you can't check into a room that's under maintenance, you can't reserve a room that's already occupied, and when a guest checks out, the room doesn't become immediately available — it needs housekeeping first. This is a textbook application of the State Pattern.

Beyond state management, hotels face a pricing complexity that mirrors what we saw with the Parking Lot (DP1), but richer. Hotel pricing varies by room type, season, day of week, length of stay, and occupancy demand. A standard room might cost $100/night on a Tuesday in January but$250/night on a Saturday during peak tourist season. This makes the Strategy Pattern essential — the same system must support multiple pricing algorithms, swappable without code changes.

This is also a frequent LLD interview question at companies like Booking.com, Airbnb, Expedia, and OYO Rooms. Interviewers look for candidates who can model state transitions cleanly, separate pricing logic from room management, and handle the multi-actor nature of the system (guests, receptionists, administrators).

By completing the Hotel Management System design problem, you will:

• Apply the State Pattern to model room lifecycle transitions — your first practical use of state-driven behavior in a design problem (Fundamentals S12)
• Apply the Strategy Pattern for pluggable pricing algorithms — seasonal, weekend, and standard pricing models that can be swapped at runtime
• Apply the Factory Method Pattern to create rooms with type-appropriate defaults — Single, Double, Deluxe, Suite
• Design a State Machine Diagram — a new UML diagram type showing room status transitions with events and guards
• Model a multi-actor system — Guests, Receptionists, and Admins with distinct capabilities
• Handle the reservation-to-checkout lifecycle — the full workflow from booking through billing
• Build a Use Case Diagram and Class Diagram with richer relationships than Easy-level problems
• Implement the complete system in Python and Java with 8-10 classes working together

This is a Medium-level problem, which means we assume you've already completed at least one Easy problem (like the Parking Lot, DP1). We'll spend less time explaining OOP basics and more time on the design trade-offs that make this system interesting.

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — Composition, Aggregation, and Association. You'll decide which applies to Hotel→Room, Reservation→Guest, and other pairs (Fundamentals S4)
• State Pattern — how objects delegate behavior to state objects and transition between states. This is the heart of room status management (Fundamentals S12)
• Strategy Pattern — interchangeable algorithms injected at runtime. We saw this with parking pricing in DP1; here we apply it to hotel pricing (Fundamentals S12)
• Factory Pattern — creating objects without exposing construction logic. We'll use this for room creation by type (Fundamentals S10)
• UML Class Diagrams and State Machine Diagrams — how to read class boxes, relationship arrows, state circles, and transition arrows (Fundamentals S5)
• At least one Easy design problem completed — ideally the Parking Lot (DP1) or Vending Machine (DP6, which also uses State Pattern)

If the State Pattern feels unfamiliar, revisit Fundamentals S12 before proceeding. The room state machine is the architectural backbone of this design — without understanding State, the code implementation won't make sense.

We will design: The core domain logic of a hotel management system — room inventory, reservations, guest check-in/check-out, room state management, billing, and pricing strategies.

We will NOT design:

• Database schemas or ORM mappings
• REST APIs or web interfaces
• Payment gateway integrations (we model billing, not actual payment processing)
• Distributed systems concerns (load balancing, caching, database sharding)
• Loyalty/rewards programs (out of scope for this problem)
• Multi-property management (we design for a single hotel)

This is a Low Level Design (object-oriented) exercise. We focus on classes, relationships, state transitions, and design patterns — not infrastructure.

We'll follow the same systematic process from Fundamentals S16 (Interview Framework):

1. Requirements — Define what the hotel system must do (functional) and how well (non-functional)
2. Use Case Diagram — Identify actors (Guest, Receptionist, Admin) and their interactions with the system
3. Class Diagram — Design the object model with all classes, attributes, methods, and relationships
4. State Machine Diagram — Model room status transitions with events, guards, and actions
5. Code Implementation — Full Python and Java implementation matching the class diagram
6. Design Patterns — Analyze how State, Strategy, and Factory patterns improve the design
7. Testing & Edge Cases — Validate with tests and identify failure scenarios
8. Summary — Consolidate the design decisions and key takeaways

The State Machine Diagram is new in this problem. We didn't use it in the Easy problems because their state management was simple enough to handle inline. The Hotel room lifecycle is complex enough to warrant a dedicated diagram — and that's a hallmark of Medium-level problems.