Design a Hotel Room Booking System
In a 45-minute LLD interview, the interviewer tests fluent validated object creation, lifecycle state enforcement, and dynamic pricing strategies. Scope the solution to: inventory management across room types (Standard, Deluxe, Suite), date-range non-overlap availability checking over half-open intervals [checkIn, checkOut), fluent construction via ReservationRequest::Builder, state transitions (Tentative → Confirmed → CheckedIn → Cancelled), and surge/seasonal pricing models. Cleaning schedules and multi-property chains can be deferred to follow-ups.
Problem statement & clarifying requirements
Design a hotel room booking system that manages room inventory across diverse room types (Standard, Deluxe, Suite). The system must validate reservation parameters fluently using the Builder Pattern, govern reservation lifecycles (Tentative → Confirmed → CheckedIn → Cancelled) using the State Pattern, and dynamically compute room charges with seasonal, holiday, and weekend multipliers via the Strategy Pattern.
Through ReservationRequest::Builder, enforcing cross-field invariants (e.g. check-out strictly after check-in, valid guest count, non-empty guest name) before creating an immutable ReservationRequest.
Four explicit states: Tentative (on hold before payment), Confirmed (payment received), CheckedIn (guest on-premise), and Cancelled. Transitions like checking in without confirmation or cancelling after check-in are strictly forbidden.
A room is available for interval [checkIn, checkOut) if no active (!= Cancelled) reservation for that room overlaps the interval: max(start1, start2) < min(end1, end2).
A PricingStrategy interface computes total cost combining room base rate, night count, add-on services (breakfast, airport shuttle, late check-out), and surge multipliers (weekend, holiday peak).
First, sketch the design yourself
Spend 5 minutes listing the classes, who owns whom, and which interface hides the part that changes.
- 1.
Builder Pattern (
b1) prevents constructor telescoping: A reservation involves multiple optional attributes (shuttle, breakfast, late check-out, special requests). The Builder pattern allows fluent construction and guarantees the final product is valid and immutable. - 2.
State Pattern (
a4) enforces valid business lifecycles: Putting state transitions inReservationwith flags leads to scatteredif (status == ...)checks. Polymorphic state objects cleanly reject invalid operations (e.g. refunding after checkout). - 3.
Date range overlap mathematics: Standard half-open intervals
[checkIn, checkOut)permit back-to-back stays where one guest checks out on the same day another guest checks in.
How to think through this problem (5-step walkthrough)
In a 45-minute LLD interview, the interviewer tests fluent validated object creation, lifecycle state enforcement, and dynamic pricing strategies. Scope the solution to: inventory management across room types (Standard, Deluxe, Suite), date-range non-overlap availability checking over half-open intervals [checkIn, checkOut), fluent construction via ReservationRequest::Builder, state transitions (Tentative → Confirmed → CheckedIn → Cancelled), and surge/seasonal pricing models. Cleaning schedules and multi-property chains can be deferred to follow-ups.
Not every noun in the prompt deserves its own class. Separate dumb data structs from stateful managers, and turn trivial nouns into fields or enums.
ReservationRequestImmutable value object encapsulating validated booking specifications (dates, guest details, room type, add-ons), constructed exclusively via its nested Builder.
ReservationRequest::BuilderFluent builder validating cross-field invariants (e.g. check-out strictly after check-in, positive guest count, non-empty guest name) before assembling the immutable request.
ReservationStatePolymorphic State contract (TentativeState, ConfirmedState, CheckedInState, CancelledState) governing permitted lifecycle transitions and rejecting illegal operations.
ReservationContext entity holding reservation ID, validated request, calculated total price, and the current std::unique_ptr<ReservationState>.
PricingStrategyStrategy contract calculating nightly stay totals, surge multipliers (weekend, peak holiday), and optional add-on fees (breakfast, airport shuttle, late checkout).
HotelBookingSystemCentral facade managing room inventory, checking date range availability across active bookings, and coordinating reservations.
NightCount / GuestNameTrap noun — NightCount is a derived scalar value (checkOut - checkIn) calculated by a helper method, and GuestName is a validated std::string, not heavy domain classes.
A beginner writes a massive Reservation constructor with 8 parameters (guestName, checkIn, checkOut, roomType, breakfast, shuttle, lateCheckout, guests). Optional parameters lead to constructor telescoping, invalid date ranges pass silently into the system, and reservation lifecycles are checked via error-prone status strings (status == "TENTATIVE"). Guests can mistakenly cancel already completed stays or check into unconfirmed bookings without compiler or runtime guards.
Telescoping constructors make code unreadable and permit invalid combinations (such as check-out preceding check-in or zero guests).
Scattered if (status == ...) checks allow illegal transitions, like checking in without payment confirmation or refunding completed bookings.
Hardcoded pricing algorithms inside the booking system prevent dynamic adjustments for peak tourist seasons, weekends, or promotional corporate discounts.
- ✓
Half-open date interval non-overlap: Two reservations for the same room overlap if and only if $\max(start_1, start_2) < \min(end_1, end_2). Reservations ending on day D do not collide with new reservations beginning on day D$.
- ✓
Strict lifecycle directionality: A reservation can only transition along valid directed edges:
Tentative → Confirmed → CheckedIn; cancellation is permitted fromTentativeorConfirmed, but strictly forbidden onceCheckedIn. - ✓
Immutable request safety: Once built by
ReservationRequest::Builder, aReservationRequestis completely immutable, preventing post-validation tampering with dates, guest counts, or room categories.
Entities & design patterns used
Unlock Full UML Diagram & C++23 Solution
The complete UML diagram, production-ready C++23 code, follow-up extensions, and design pitfall analysis are part of Brute2Best Pro. All 7 foundation chapters are 100% free.
First anchor question per pattern, Part 1 LLD & Module 1 C++ basics are 100% Free forever.