Hotel Management System

Reservations, Billing & Operations

Design a hotel system that books room types for date ranges without overbooking any night, assigns a clean room at check-in, prices each night through stacked rules, and tracks rooms through cleaning.

Overview

A hotel sells nights, not rooms. A guest books a room type (standard, deluxe, suite) for a range of dates, and only when they arrive does the front desk give them a particular room. In between, the system must make sure that on every night of every stay it has not promised more rooms of a type than the hotel owns. When the guest leaves, the room needs cleaning before anyone else can use it, and the bill adds up each night's price plus anything charged to the room.

The problem tests four things. First, separating the reservation (a type and dates) from the room assignment (a room number at check-in), which is the move that makes the rest simple. Second, date ranges: a stay from Thursday to Sunday uses the nights of Thursday, Friday and Saturday, and two stays that touch on one day do not overlap. Third, a room status state machine so that nobody checks into a dirty room. Fourth, pricing as a chain of small rules, because rates change more often than anything else.

A strong answer states the half-open date rule early, counts bookings per type per night, draws the room states, and demos an overlap refusal, an upgrade and a bill.

Scoping the problem

Does a guest book a room type or a specific room? — Decides the inventory model — A type; the room is given at check-in
Is the check-out day a night of the stay? — The off-by-one that breaks overlap checks — No: stays are half-open, check-in included, check-out excluded
What if no clean room of the type is free at check-in? — Upgrade, wait, or move to another hotel — Upgrade to the next type at no extra charge
How are prices set? — Seasonal, weekend, long-stay, corporate — Stacked rules applied to each night
Are extras charged to the room? — Adds line items to the bill — Yes
Overbooking on purpose? — Changes the capacity check — No in the core; a follow-up
Several front desks and websites at once? — Decides the locking — Yes; a night must never be oversold

Nights, not rooms

The inventory is a count per room type per night: booked[(type, night)]. A booking is allowed only if every night of the stay has a count below the number of rooms of that type, and then every one of those counts goes up by one, all under one lock so two desks cannot both take the last room.

The demo hotel has two standard rooms. Stays are half-open: [check-in, check-out).

Ana, Thu to Sun — Thu, Fri, Sat — 1 — 1 — 1 — booked
Raj, Fri to Sat — Fri — 1 — 2 — 1 — booked
Lee, Fri to Sun — Fri, Sat — 1 — 2 — 1 — refused: Friday is full
Lee, Sat to Sun — Sat — 1 — 2 — 2 — booked: Raj's stay ends Saturday morning

Counting per night instead of comparing reservations pairwise makes the check O(nights) and makes the rule obvious. It also works for any number of rooms of a type.

A room's day

There is no RESERVED state on a room, on purpose. Reservations hold a type, not a room, so a room is only ever empty, in use, waiting for cleaning, or out of order.

Pricing as stacked rules

Each night starts at the room type's base rate and passes through the rules in order. Money is kept in integer cents, and each percentage rounds down.

Standard, Thu (3-night stay) — 100.00 — 100.00 — not 7 nights — 100.00
Standard, Fri (3-night stay) — 100.00 — 125.00 — not 7 nights — 125.00
Suite, Mon (7-night stay) — 300.00 — 300.00 — 270.00 — 270.00
Suite, Sat (7-night stay) — 300.00 — 375.00 — 337.50 — 337.50

Ana's Thursday-to-Sunday stay is 100 + 125 + 125 = 350.00. The 7-night suite stay is 5 × 270.00 + 2 × 337.50 = 1,687.50. The order of rules matters when they mix additions and percentages, so keep it explicit in a list.

What you will be able to do

Separate a reservation (type and dates) from a room assignment and explain why.
Check availability per type per night with half-open date ranges.
Enforce room states with one transition table and keep dirty rooms away from guests.
Price each night through stacked rules and build the bill from room charges and extras.
Make booking safe under many desks with one lock around check-and-take.

Functional requirements

available(type, check_in, check_out) returns how many rooms of a type are free on every night of the stay
book(guest, type, check_in, check_out) reserves a room type for the stay or refuses if any night is full
cancel(id) returns every night of a booked reservation to inventory
check_in(id) assigns an AVAILABLE room of the booked type, or of the next type up as a free upgrade when that type has a spare room every night
add_extra(id, description, cents) charges services to an in-house guest
check_out(id) returns the total (room charge plus extras) and sends the room to housekeeping
cleaned(number) and set_maintenance(number, on) move rooms through their states

Non-functional requirements

No night is sold beyond the rooms of its type, even with many desks booking at once
Stays are half-open date ranges; back-to-back stays never conflict
Room status changes follow one transition table
A new pricing rule is a new class added to the list; the Hotel class does not change
Money in integer cents; percentages round down and in a fixed order

Interview questions

How would you make sure the database never oversells a night?
An upgrade gives a standard guest a deluxe room. What can go wrong?
How would you add overbooking on purpose?
How does housekeeping decide which room to clean first?