Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
Hotel Booking System — LLD Deep Dive
Design a hotel booking system using object-oriented design patterns — State machine for booking lifecycle, Strategy for dynamic pricing, and optimistic locking to prevent double-booking. Covers availability modeling, cancellation policies, and chain-scale extension.
What Interviewers Are Actually Testing
Hotel booking is a concurrency problem disguised as a CRUD problem. Interviewers use it to test three things: (1) availability modeling — candidates who use a day-by-day boolean table reveal they've never thought about query performance; (2) pricing separation — pricing logic embedded in Room violates SRP and is a red flag; (3) the double-booking race condition — candidates who say 'just check if the room is available before booking' miss the gap between check and write. If you don't address concurrency unprompted, the interviewer will ask about it, and your answer determines whether you pass.
Clarifying Questions — Establish Scope Before Drawing Anything
Single hotel or a chain of properties?
Single hotel means Hotel is the root aggregate. A chain of 500 properties means Hotel becomes a child of HotelChain, search must span properties, and availability queries become distributed. Design single-hotel, then offer to extend — chain adds HotelChain, centralizes search, and each Hotel delegates booking to a shared BookingService.
What room types need to be modeled?
Standard, Deluxe, Suite, Penthouse — each has a distinct base rate and amenity set. Are room types a first-class entity (RoomType class) or a simple enum? First-class entity wins when pricing, amenities, and capacity differ per type. An enum is sufficient only if all rooms of the same type are identical.
Is pricing dynamic or fixed?
Dynamic pricing (weekend premium, seasonal surge, occupancy-based adjustment) is almost always in scope. This drives PricingEngine as a mandatory separate component — not a method on Room. Confirm whether the interviewer wants the pricing algorithm or just the structure.
What cancellation policies exist?
Typical: free cancellation before 48h, 50% penalty within 24h–48h, no refund within 12h. These are variable rules that map cleanly to a Strategy pattern — CancellationPolicy is an interface with multiple implementations.
What payment model is expected?
Pay-now vs pay-at-hotel vs deposit. Does the system store card details (PCI scope)? For LLD scope, model a Payment record and a PaymentProcessor interface, don't implement card processing. Booking transitions depend on payment outcome.
Is there loyalty program integration or OTA (Expedia/Booking.com) connectivity?
OTA integration adds an ExternalBookingAdapter and idempotency requirements on BookingService (same booking_ref shouldn't create duplicates). Out of scope for initial design, but name it as an extension.