Case Study: A Hotel Booking System

Case Study: A Hotel Booking System — Tech Epitome

The brief

Guests search a hotel for available rooms between two dates, choose a room type, hold it while they enter payment details, and confirm. They may cancel later and receive a refund according to the cancellation terms they booked under. Staff check guests in, assign rooms and check them out. Rate management, housekeeping and loyalty schemes are out of scope.

Entities

Entity	Is the only thing that knows
Hotel	Its room types, rooms and local time zone
RoomType	A category (Deluxe King) and how many rooms of it exist
Room	One physical room's number and condition
Stay	A check-in and check-out date — an immutable value
NightInventory	For one room type and one night: total, held and booked counts
Reservation	One guest's claim on a room type for a stay, its status and agreed terms
CancellationPolicy	How much is refunded when a booking is cancelled at a given time

Room and RoomType are as distinct as Book and BookCopy in the library.

Concept

Book the type, assign the room

A guest does not care whether they get room 412 or 415, only that it is a Deluxe King. Booking against the room type, and assigning a room at check-in, lets the hotel fill gaps that room-level booking would leave empty.

Before and after

Same hotel, same nights

Book room 412 for Mon–Wed

Mon: 412 free

Tue: 412 taken

result: unavailable

(415 was free Tue)

Book DELUXE for Mon–Wed

Mon: 3 of 10 left

Tue: 1 of 10 left

result: bookable

java

1public record Stay(LocalDate checkIn, LocalDate checkOut) {2    public Stay {3        if (!checkOut.isAfter(checkIn))4            throw new IllegalArgumentException("a stay is at least one night");5    }6 7    public long nights() { return ChronoUnit.DAYS.between(checkIn, checkOut); }8 9    /** Half-open: [checkIn, checkOut). Back-to-back stays do not overlap. */10    public boolean overlaps(Stay other) {11        return checkIn.isBefore(other.checkOut) && other.checkIn.isBefore(checkOut);12    }13 14    public Stream<LocalDate> eachNight() { return checkIn.datesUntil(checkOut); }15}

The nights of a stay are check-in up to, not including, check-out.

Availability is inventory per night

Availability questions are per night: is there a Deluxe King free on the 12th, the 13th and the 14th? So store one inventory row per room type per night, holding the total and how many are held or booked. Available is total minus held minus booked. A three-night stay is bookable only if all three rows have room, and it must take all three or none.

sql

1-- One row per room type per night: total, held, booked.2UPDATE room_inventory3   SET held = held + 14 WHERE room_type_id = 75   AND night >= DATE '2026-11-12'6   AND night <  DATE '2026-11-15'7   AND held + booked < total;8 9-- Expect 3 rows (one per night). Fewer means a night is full: ROLLBACK.

The availability check is inside the write, so there is no gap to race through.

java

1final class InventoryService {2 3    @Transactional4    Reservation hold(RoomTypeId type, Stay stay, GuestId guest, CancellationPolicy terms, Money price) {5        int updated = inventory.incrementHeldIfAvailable(type, stay);   // the UPDATE above6        if (updated != stay.nights())7            throw new SoldOut(type, stay);       // exception rolls back every night8        Instant expiresAt = clock.instant().plus(HOLD_DURATION);9        return reservations.save(Reservation.held(type, stay, guest, terms, price, expiresAt));10    }11}

All nights or none, in one transaction.

Holds and the reservation lifecycle

Entering card details takes minutes. The guest needs the room kept for them during that time, but a database lock must last milliseconds. So the hold is the reservation's first state: inventory is counted as held, and the reservation carries an expiry. Confirming moves held to booked; expiry releases it.

From	Event	To	Inventory effect
—	Guest holds a stay	HELD	held + 1 on each night
HELD	Payment confirmed before expiry	CONFIRMED	held − 1, booked + 1
HELD	Expiry passes	EXPIRED	held − 1
CONFIRMED	Guest cancels	CANCELLED	booked − 1; refund per policy
CONFIRMED	Guest arrives	CHECKED_IN	Room assigned
CONFIRMED	Check-in day ends without arrival	NO_SHOW	Charged per policy
CHECKED_IN	Guest leaves	CHECKED_OUT

java

1final class Reservation {2    private final ReservationId id;3    private Status status;4    private final Instant holdExpiresAt;5    private final Money price;                    // agreed at booking6    private final CancellationPolicy terms;       // agreed at booking7    private PaymentReference payment;8 9    void confirm(PaymentReference payment, Instant now) {10        if (status != Status.HELD)11            throw new IllegalStateException("cannot confirm a " + status + " reservation");12        if (!now.isBefore(holdExpiresAt))13            throw new HoldExpired(id);            // a sweeper releases the inventory14        this.payment = payment;15        this.status = Status.CONFIRMED;16    }17 18    Money cancel(ZonedDateTime checkInAt, ZonedDateTime now) {19        if (status != Status.CONFIRMED)20            throw new IllegalStateException("cannot cancel a " + status + " reservation");21        status = Status.CANCELLED;22        return terms.refund(price, checkInAt, now);23    }24}

The reservation guards its own transitions; the service adjusts inventory to match.

Cancellation policies

java

1interface CancellationPolicy {2    Money refund(Money paid, ZonedDateTime checkInAt, ZonedDateTime cancelledAt);3}4 5final class FreeUntil implements CancellationPolicy {6    private final Duration notice;                // e.g. 48 hours7 8    public Money refund(Money paid, ZonedDateTime checkInAt, ZonedDateTime at) {9        return at.isBefore(checkInAt.minus(notice)) ? paid : Money.zero(paid.currency());10    }11}12 13final class NonRefundable implements CancellationPolicy {14    public Money refund(Money paid, ZonedDateTime checkInAt, ZonedDateTime at) {15        return Money.zero(paid.currency());16    }17}

Check-in time is zoned: '48 hours before check-in' means the hotel's local time, not the server's.

python

1from dataclasses import dataclass2from datetime import datetime, timedelta3 4 5@dataclass(frozen=True)6class Tier:7    at_least_before: timedelta8    refund_percent: int9 10 11@dataclass(frozen=True)12class TieredPolicy:13    tiers: tuple[Tier, ...]          # most generous first14 15    def refund_cents(self, paid_cents: int, check_in: datetime, cancelled_at: datetime) -> int:16        notice = check_in - cancelled_at17        for tier in self.tiers:18            if notice >= tier.at_least_before:19                return paid_cents * tier.refund_percent // 10020        return 021 22 23policy = TieredPolicy((Tier(timedelta(days=7), 100), Tier(timedelta(days=2), 50)))

A tiered policy is just data plus one loop — and frozen, so it can be shared safely.

Approaches

Keeping two guests out of the last room

Lock inventory rows, then check
Time
Waits under contention
Space
Row locks per txn
Very hot dates where conflicting retries would be wasteful. Keep the transaction to the update and nothing else.
Conditional counter update
Taught here
Time
One statement per stay
Space
One row per type per night
The default. The check is part of the write, all nights succeed or the transaction rolls back.
Single writer per hotel
Time
Serialised per hotel
Space
One queue per hotel
Very complex allocation rules that are hard to express as one conditional update; throughput per hotel is modest anyway.

Extensions

Overbooking: allow held + booked to reach a configured multiple of total. One number in the condition, but a policy decision with real costs, so it belongs in a named, owned setting.
Multi-room bookings: hold every room type in one transaction, so a family's two rooms are all-or-nothing.
Payment retries: confirming must be idempotent, keyed on the payment reference, or a retried confirmation charges twice.
Selling through several travel sites: each channel becomes a client of the same inventory rows; whatever the channel, the conditional update stays the single point where availability is decided.

Case Study: A Hotel Booking System

The brief

Entities

Book the type, assign the room

Same hotel, same nights

Availability is inventory per night

Holds and the reservation lifecycle

Cancellation policies

Keeping two guests out of the last room

Lock inventory rows, then check

Conditional counter update

Single writer per hotel

Extensions

You’ve reached the end

Assign rooms at booking with (room, night) unique

Search Tech Epitome

Search Tech Epitome

Case Study: A Hotel Booking System

The brief

Entities

Book the type, assign the room

Same hotel, same nights

Availability is inventory per night

Holds and the reservation lifecycle

Cancellation policies

Keeping two guests out of the last room

Lock inventory rows, then check

Conditional counter update

Single writer per hotel

Extensions

You’ve reached the end

Assign rooms at booking with (room, night) unique