Hotel Management System

Problem Statement

Design a Hotel Management System that handles the complete lifecycle of a guest's stay - from searching and booking rooms, through check-in and check-out, to billing and housekeeping coordination. The system should support a mid-to-large hotel (or hotel chain) with multiple room types across multiple floors, handle concurrent reservations without double-booking, manage dynamic pricing, coordinate housekeeping staff, and process payments for room charges and additional services.

Consider a scenario where a guest searches for available rooms for specific dates, makes a reservation, arrives and checks in (possibly receiving a room different from the one initially reserved), orders room service during the stay, and finally checks out with an itemized bill. Simultaneously, housekeeping staff need real-time notifications when rooms are vacated, front-desk staff handle walk-in guests, and the system must prevent two guests from being assigned the same room for overlapping dates.

This is a classic object-oriented design problem that tests your ability to model complex real-world workflows with multiple interacting actors (guests, front-desk agents, housekeeping staff, managers), state machines (room lifecycle), financial transactions (billing and payments), and concurrency challenges (simultaneous bookings from multiple channels). The system must balance operational efficiency with guest satisfaction while maintaining data integrity across all operations.

---

Requirements

Functional Requirements

1. Room Search & Availability - Search available rooms by date range, room type (Single, Double, Suite, Deluxe), floor preference, and amenities. Display real-time availability with pricing.

2. Reservation Management - Create, modify, and cancel reservations. Support guaranteed reservations (credit card hold) and non-guaranteed reservations with cancellation deadlines.

3. Check-in / Check-out - Process guest arrival with ID verification, assign a physical room, issue room key. Handle early check-in and late check-out with appropriate charges.

4. Room Assignment - Allocate specific rooms at check-in time based on guest preferences, loyalty status, and availability. Support room upgrades and downgrades.

5. Billing & Invoicing - Track room charges (nightly rate × nights), additional services (room service, laundry, minibar, spa), taxes, and discounts. Generate itemized bills.

6. Payment Processing - Accept multiple payment methods (credit card, cash, corporate billing). Handle pre-authorization, partial payments, split bills, and refunds.

7. Housekeeping Management - Track room cleanliness status, assign cleaning tasks to staff, prioritize rooms (checkout rooms first, then stayovers), and mark rooms as ready for new guests.

8. Guest Management - Maintain guest profiles with stay history, preferences, loyalty tier, and contact information. Support returning guest recognition.

Non-Functional Requirements

1. Concurrency Control - Prevent double-booking when multiple agents or online channels attempt to reserve the same room simultaneously.

2. Real-time Availability - Room status changes (booking, checkout, cleaning complete) must propagate within seconds across all channels.

3. Data Consistency - Financial transactions and room state must maintain ACID properties. No lost reservations or phantom charges.

4. Scalability - Support hotel chains with hundreds of properties, thousands of rooms, and millions of annual reservations.

5. High Availability - The system must remain operational 24/7; hotels never close.

6. Audit Trail - All booking modifications, cancellations, and financial transactions must be logged for compliance.

---

Constraints & Assumptions

• Room Types: Single (1 bed), Double (2 beds), Suite (living area + bedroom), Deluxe (premium amenities). Each type has a base rate.
• Floor Layout: Hotel has 10+ floors, each with 20-30 rooms. Some floors are premium (higher floors = higher rate).
• Seasonal Pricing: Rates vary by season (peak, off-peak, holiday). Dynamic pricing may adjust based on occupancy percentage.
• Check-in/Check-out Times: Standard check-in at 3:00 PM, check-out at 11:00 AM. Early check-in and late check-out available for additional fees if room is available.
• Overbooking Policy: Hotel may overbook by 5-10% to account for no-shows and cancellations (industry standard).
• Cancellation Policy: Free cancellation up to 24 hours before check-in; one night's charge for late cancellation or no-show.
• Reservation Hold: Non-guaranteed reservations are released at 6:00 PM on check-in date if guest hasn't arrived.
• Multi-channel Booking: Reservations come from front desk, phone, website, and third-party OTAs (Online Travel Agencies).

---

Key Entities & Relationships

Key Relationships:

• A Guest makes multiple Reservations over time
• A Reservation is for a room type (not a specific room initially)
• A Booking is created at check-in, linking a Reservation to a specific Room
• A Bill aggregates all charges for a Booking
• HousekeepingTasks are triggered by checkout events and scheduled maintenance

---

ASCII Class Diagram

┌─────────────────────────────────────────────────────────────────────┐
│                              HOTEL                                    │
│  id, name, address, starRating                                       │
├─────────────────────────────────────────────────────────────────────┤
│  + searchAvailableRooms(dateRange, type, floor)                      │
│  + getOccupancyRate()                                                │
└──────────┬──────────────────────────────────┬───────────────────────┘
           │ 1:N                              │ 1:N
           ▼                                  ▼
┌─────────────────┐                 ┌──────────────────┐
│     FLOOR       │                 │      STAFF       │
│ floorNum, wing  │                 │ name, role, shift│
├─────────────────┤                 └──────────────────┘
│ + getRooms()    │                          │
└────────┬────────┘                          │ assigned to
         │ 1:N                               ▼
         ▼                          ┌──────────────────────┐
┌─────────────────────┐             │  HOUSEKEEPING_TASK   │
│        ROOM         │◄────────────│ priority, status,    │
│ number, type, rate  │  assigned   │ scheduledTime        │
│ maxOccupancy        │             └──────────────────────┘
├─────────────────────┤
│ + getStatus()       │
│ + updateStatus()    │
└────────┬────────────┘
         │
         │ allocated at check-in
         ▼
┌─────────────────────────┐        ┌─────────────────────┐
│       BOOKING           │        │       GUEST         │
│ actualCheckIn/Out       │◄───────│ name, email, loyalty│
│ keyCardId               │        │ preferences         │
├─────────────────────────┤        ├─────────────────────┤
│ + generateBill()        │        │ + getStayHistory()  │
│ + addService()          │        │ + getReservations() │
└────────┬────────────────┘        └──────────┬──────────┘
         │ 1:1                                │ 1:N
         ▼                                    ▼
┌─────────────────────┐             ┌─────────────────────────┐
│       BILL          │             │     RESERVATION         │
│ lineItems[], total  │             │ roomType, dates, status  │
│ tax, discounts      │             │ specialRequests          │
├─────────────────────┤             ├─────────────────────────┤
│ + addCharge()       │             │ + confirm() / cancel()  │
│ + calculateTotal()  │             │ + modify()              │
└────────┬────────────┘             └─────────────────────────┘
         │ 1:N
         ▼
┌─────────────────────┐
│      PAYMENT        │
│ amount, method      │
│ transactionId       │
└─────────────────────┘

State Diagram - Room Status:

                    ┌──────────┐
         ┌────────►│ AVAILABLE│◄──────────────┐
         │         └─────┬────┘               │
         │               │ reserve            │ cleaning complete
         │               ▼                    │
         │         ┌──────────┐         ┌─────┴─────┐
  cancel │         │ RESERVED │         │  CLEANING  │
         │         └─────┬────┘         └─────▲─────┘
         │               │ check-in           │
         │               ▼                    │ checkout
         │         ┌──────────┐               │
         └─────────│ OCCUPIED │───────────────┘
                   └─────┬────┘
                         │ maintenance needed
                         ▼
                   ┌─────────────┐
                   │ MAINTENANCE │──── repair complete ───► CLEANING
                   └─────────────┘

---

Design Decisions & Trade-offs

1. Room Allocation Strategy

Decision: Allocate at check-in. Reserve by type and assign a specific room when the guest arrives. This allows the hotel to optimize floor assignments based on actual occupancy and housekeeping readiness.

2. Overbooking Handling

Decision: Allow controlled overbooking (configurable percentage per room type). Implement a "walk" protocol: if overbooked, offer upgrades first, then arrange accommodation at a partner hotel with compensation.

3. Pricing Strategy

Decision: Use the Strategy pattern with a chain of pricing rules:

1. Base rate - per room type
2. Seasonal modifier - multiplier based on date (peak = 1.5x, holiday = 2x)
3. Occupancy-based dynamic pricing - increase rate as occupancy exceeds 80%
4. Loyalty discount - percentage off for loyalty members
5. Package deals - bundled rates (room + breakfast + spa)

The pricing engine evaluates all applicable strategies and computes the final rate.

4. Concurrency for Same-Room Booking

Decision: Use pessimistic locking at the reservation level with short lock durations (30-second hold during booking flow). For high-traffic online channels, use optimistic locking with version checks and graceful conflict resolution ("Sorry, this room was just booked. Here are alternatives.").

5. Housekeeping Scheduling

Decision: Hybrid priority-based approach:

1. Priority 1 - Checkout rooms with incoming reservations today (must be ready by 3 PM)
2. Priority 2 - Checkout rooms without same-day reservations
3. Priority 3 - Stayover rooms (daily cleaning)
4. Priority 4 - Deep cleaning and maintenance

Assign tasks by floor clusters to minimize staff travel time. Use the Observer pattern to auto-generate tasks when checkout occurs.

---

Design Patterns Used

Strategy Pattern - Pricing

PricingStrategy (interface)
├── SeasonalPricing
├── DynamicOccupancyPricing
├── LoyaltyDiscountPricing
└── PackageDealPricing

PricingEngine applies strategies in sequence to compute final rate.

The pricing engine accepts a list of strategies and applies them in order. New pricing rules (corporate rates, promotional codes) can be added without modifying existing code.

State Pattern - Room Status

Room delegates behavior to its current state object. Each state (Available, Occupied, Reserved, Maintenance, Cleaning) defines valid transitions and actions. For example, only an Available room can transition to Reserved, and only an Occupied room can transition to Cleaning (via checkout). Invalid transitions throw exceptions - you cannot check a guest into a room that's in Maintenance state. This pattern eliminates complex conditional logic scattered throughout the codebase and makes adding new states (e.g., "Inspecting" between Cleaning and Available) straightforward without modifying existing state classes.

Observer Pattern - Housekeeping Notifications

When a room's status changes to "Cleaning" (triggered by checkout), the system notifies the HousekeepingService, which creates a task and assigns it to available staff on that floor. The front desk is also notified when cleaning is complete so they can assign the room to waiting guests. Multiple observers can subscribe to room status change events: the housekeeping scheduler, the front desk dashboard, the revenue management system (for real-time occupancy tracking), and the OTA channel manager (to update external availability). This decouples the checkout process from all downstream actions.

Factory Pattern - Room Creation

A RoomFactory creates room instances based on type, automatically setting the correct base rate, max occupancy, amenity list, and floor assignment rules. Useful when onboarding new properties in a hotel chain.

Builder Pattern - Reservation

Reservations have many optional parameters (special requests, bed preference, accessibility needs, loyalty number, corporate code, package selection). The ReservationBuilder provides a fluent interface to construct complex reservations step by step.

Command Pattern - Booking Operations

Each booking operation (create, modify, cancel) is encapsulated as a command object. This enables:

• Undo/Redo - Cancel a cancellation (reinstate booking)
• Audit logging - Every command is logged with timestamp and actor
• Queuing - Commands can be queued during high-load periods

---

Edge Cases

1. Double Booking Race Condition

Two agents book the last available Suite for the same dates simultaneously. Solution: Database-level unique constraint on (room_id, date) pairs in an occupancy table, combined with pessimistic locking during the booking transaction.

2. No-Show Handling

Guest doesn't arrive by 6 PM (non-guaranteed) or at all (guaranteed). Solution: Automated job releases non-guaranteed reservations at the deadline. Guaranteed no-shows are charged one night and the room is released for walk-ins.

3. Early Checkout Refund

Guest checks out 2 days early on a 5-night stay. Solution: Apply cancellation policy to remaining nights. Configurable: full refund, partial refund, or no refund based on rate type (flexible vs. non-refundable).

4. Room Upgrade/Downgrade

Requested room type unavailable at check-in. Solution: Offer complimentary upgrade if higher-tier room is available. If only lower-tier is available, offer discount or reschedule. Log all changes for billing accuracy.

5. Group Bookings

A conference group books 50 rooms. Solution: Group reservation entity with block allocation, shared billing (master folio + individual folios), group check-in workflow, and rooming list management. Support block release dates where unbooked rooms in the block return to general inventory. Track attrition (actual pickup vs. contracted block size) for penalty calculations.

6. Maintenance During Occupied Period

A pipe bursts in an occupied room. Solution: Trigger emergency room change workflow - find equivalent room, transfer guest belongings, update key cards, adjust billing, create incident report. Automatically deactivate the old room key, issue a new key for the replacement room, and apply a courtesy credit to the guest's folio for the inconvenience.

7. Payment Failure After Check-in

Credit card declines during the stay. Solution: Attempt re-authorization daily. After N failures, alert front desk for manual resolution. Maintain a "payment hold" status that restricts additional service charges until resolved. For high-value stays, require a secondary payment method at check-in as backup. Track outstanding balances and escalate to collections if unresolved at checkout.

---

Extensibility Points

1. Multi-Property Management - Abstract Hotel into a chain hierarchy. Central reservation system with property-level autonomy. Cross-property availability search and transfer.

2. Loyalty Programs - Points accrual per stay, tier-based benefits (upgrades, late checkout, lounge access), redemption for free nights. Integrate with the pricing strategy chain.

3. Third-Party Booking Integration (OTA) - Channel manager module that syncs availability and rates with Booking.com, Expedia, Airbnb. Handle rate parity rules and commission tracking.

4. Conference Room Booking - Extend the room concept to include meeting spaces with hourly booking, AV equipment, catering packages, and setup/teardown scheduling.

5. Restaurant & Spa Booking - Table reservation system and spa appointment scheduling integrated with guest profiles. Charges posted to room folio automatically.

6. IoT Integration - Smart room controls (thermostat, lighting), minibar sensors for automatic charge detection, digital key via mobile app, occupancy sensors for energy management. The system receives events from IoT devices and translates them into billing actions or maintenance alerts.

7. Revenue Management System - ML-based demand forecasting, automated rate optimization, competitor rate monitoring, and yield management dashboards. Integrates with the pricing strategy chain to dynamically adjust rates based on predicted demand curves and market conditions.

8. Mobile Guest Experience - Self-service check-in/check-out via mobile app, digital room key, in-app service requests, real-time bill viewing, and push notifications for room readiness. Reduces front-desk load and improves guest convenience.

---

Interview Follow-ups

Q1: How would you handle a hotel chain with 500 properties and centralized booking?

Answer: Implement a federated architecture. Each property maintains its own operational database for real-time operations (check-in, housekeeping). A central reservation system aggregates availability across properties using eventual consistency (availability snapshots synced every few seconds). Booking requests are routed to the specific property's system for final confirmation with strong consistency. Use a message queue (Kafka/SQS) for cross-property event propagation. The central system handles cross-property searches, loyalty programs, and reporting.

Q2: How do you prevent stale availability data when multiple channels are booking simultaneously?

Answer: Implement a "last room availability" (LRA) protocol. When inventory drops below a threshold (e.g., 3 rooms of a type), switch from cached availability to real-time database checks. Use database-level constraints (unique index on room-date pairs) as the final safety net. For OTA channels, push availability updates via webhooks within seconds of any booking. Accept that brief windows of stale data exist but handle conflicts gracefully with waitlisting or alternatives.

Q3: How would you design the billing system to handle split payments and corporate billing?

Answer: Use a folio-based billing model. Each booking has a master folio. Charges are posted to the folio as line items with categories. At checkout, the folio can be split into multiple payment instructions: "Room charges to corporate card, personal minibar to guest card, spa to cash." Each payment instruction references specific line items or a percentage split. Corporate billing generates an invoice sent to the company's AP department with NET-30 terms, tracked separately from immediate payments.

Q4: How would you implement dynamic pricing that responds to real-time demand?

Hint: Consider occupancy thresholds that trigger rate tier changes. Think about how airlines use booking curves (expected vs. actual bookings over time). Factor in day-of-week patterns, local events, and competitor rates.

Q5: How would you design the system to handle a complete property outage (network failure at a hotel)?

Hint: Think about offline-capable operations at the property level. Consider what operations are critical (check-in, key issuance) vs. deferrable (loyalty point accrual, OTA sync). Look at conflict resolution strategies when the property reconnects.

---

Counter Questions to Ask Interviewer

Before diving into design, clarify scope with these questions:

1. Scale: Are we designing for a single hotel or a chain? How many rooms and properties?
2. Booking channels: Do we need to integrate with third-party OTAs, or only direct bookings?
3. Overbooking: Does the business allow overbooking? What's the acceptable walk rate?
4. Payment complexity: Do we need to support corporate billing, split folios, and multi-currency?
5. Real-time requirements: How quickly must availability updates propagate across channels?
6. Guest types: Do we need to handle group bookings, long-term stays (30+ days), or hourly bookings?
7. Housekeeping scope: Is housekeeping scheduling in scope, or just room status tracking?
8. Loyalty program: Is there an existing loyalty system to integrate with, or do we design one?
9. Regulatory: Are there specific compliance requirements (PCI-DSS for payments, GDPR for guest data)?
10. Existing systems: Are we replacing a legacy system or building greenfield? Any integration constraints?

---

References

1. Design Patterns: Elements of Reusable Object-Oriented Software - Gamma et al. (Gang of Four) - Strategy, State, Observer, Factory, Builder, Command patterns.
2. Opera PMS (Oracle Hospitality) - Industry-standard property management system architecture reference.
3. HTNG (Hotel Technology Next Generation) - Industry standards for hotel system integration and data exchange.
4. Revenue Management and Pricing - Talluri & van Ryzin - Dynamic pricing and overbooking theory.
5. OpenTravel Alliance (OTA) Specifications - Standard message formats for hotel availability, booking, and rate exchange.
6. PCI-DSS Compliance Guidelines - Payment Card Industry standards for handling credit card data in hospitality systems.
7. Domain-Driven Design - Eric Evans - Bounded contexts applicable to separating Reservations, Billing, and Housekeeping domains.

Related Topics

• Strategy Pattern
• State Pattern
• Observer Pattern
• Builder Pattern
• Database Design and Integration