Hotel Reservation Trade-offs & Decisions

The invariant (Complete Design, Chapter 01) says confirmed stays never exceed sellable rooms. Airlines and many hotels deliberately sell past capacity because some guests never arrive, so the first decision is whether the platform enforces the invariant strictly or sells against a modeled margin.

Selection criteria. Whether no-show rates are predictable per property and night, who carries the liability for a walked guest (the hotel or the platform), and whether the product can promise anything weaker than a guaranteed room.

Choice for this workload. Strict no-oversell. The platform is a reseller of the hotel's inventory and owns no walk process, so a confirmation must be unconditional.

When another option wins. A hotel's own revenue-management team with stable no-show history and a walk agreement. Model it as an overbook_margin column decided by the hotel; the CHECK becomes held + confirmed <= sellable + overbook_margin, and every other mechanism is unchanged.

Remaining risk. The guarantee holds against the platform ledger only. Rooms sold on other channels arrive through PMS sync and can still collide with platform bookings (Decision 12).

The data model (Complete Design, Chapter 06) counts rooms per (hotel_id, room_type_id, stay_date). The alternative is to assign room 412 at booking time. The traveler needs a Deluxe room; housekeeping, maintenance and late checkouts are same-day facts.

Selection criteria. Whether units of a type are interchangeable to the traveler, and whether the product sells a specific unit.

Choice for this workload. Room-type counts. If every night's count stays within the type's rooms, a check-in-time assignment without moves always exists: a stay is an interval of nights, and assigning rooms in order of arrival never needs more rooms than the busiest night does. Room moves appear only when rooms are fixed early or a room drops out of service.

When another option wins. Products that sell a specific room. Model unique units as their own room type, or keep per-room interval rows (Decision 04) for that segment only.

Remaining risk. A room that goes out of order after the type is sold out leaves sellable below held + confirmed; that is a capacity conflict for the hotel to resolve (Architecture Deep Dive 13).

Allocation needs one transaction over several rows (nights, hold, outbox) with durable commits. The load is modest: ~45 booking attempts/s and about 135 write transactions/s at peak, over ~60 M room-night rows (Complete Design, Chapter 05).

Selection criteria. Transaction scope (several rows atomically), durability, write rate against one primary's capacity, and operational familiarity.

Choice for this workload. A relational database. The write rate is far below one primary's capacity, and every invariant is a constraint or a conditional UPDATE the engine already enforces.

When another option wins. Distributed SQL when bookings must be accepted in several regions at once with no data loss on a regional failure. An in-memory store only as an admission gate in front of the database during extreme spikes, never as the authority.

Remaining risk. Hot-row throughput: 50-200 attempts on one room-night serialize at roughly 200-500 allocations/s whatever the store; short transactions and fail-fast 409s are the only remedy.

The invariant is per night, but a search asks about a range of nights. The storage shape decides whether writes lock exactly the nights they touch and how expensive a range read is (Complete Design, Chapter 06).

Selection criteria. Lock granularity on the write path, read cost on the search path, and whether the product allocates types or rooms.

Choice for this workload. Per-night rows for authority, and a per-room-type nightly array as the read-side projection (Architecture Deep Dive 10), so each path gets the shape that suits it.

When another option wins. Per-room intervals when physical rooms are sold. A calendar write model only where writes are rare and one writer owns the calendar.

Remaining risk. Long stays lock many rows; a MAX_STAY_NIGHTS bound caps statements and lock time.

Stage 1 (Complete Design, Chapter 09) faces ~1,800 search QPS, bursting to ~5,400 availability reads/s, against ~45 booking attempts/s. The question is where those reads go.

Selection criteria. Read volume, how much staleness a browsing signal tolerates, and whether search load may touch the booking path.

Choice for this workload. The projection, with the authoritative check made by the conditional UPDATE in the hold transaction. A stale positive costs a failed hold (409); a stale negative costs a missed sale until the lag catches up.

When another option wins. Low-QPS, correctness-sensitive views such as the hotel extranet read the primary or a replica. A small platform can start with replicas.

Remaining risk. Stale negatives on scarce nights lose sales during lag spikes; projection lag is an alerted SLO.

Having chosen a projection (Decision 05), the design must keep it within ~60 s of the authoritative rows without slowing the booking path (Architecture Deep Dive 10).

Selection criteria. Freshness target, coupling to the booking path, and whether the same change stream has other consumers.

Choice for this workload. Incremental from the outbox: the event is one extra insert in a transaction that already exists, and the same stream drives notifications and refunds. A rebuild is kept for bootstrap and schema changes.

When another option wins. CDC when many writers bypass the service (legacy tools, bulk loads). Push (WebSocket/SSE) on top of either when live counters are a product feature; it changes delivery, not freshness.

Remaining risk. Relay or projector backlog stretches lag; outbox age and projection lag are alerted.

Stage 2 (Complete Design, Chapter 10) showed the lost update; Stage 3 (Complete Design, Chapter 11) needs a concurrency control that stays correct and fast when 50-200 attempts hit one room-night within seconds.

Selection criteria. Expected contention on the hottest row, whether the rule fits in a predicate, and how long locks are held.

Choice for this workload. The conditional UPDATE at READ COMMITTED, in ascending key order (Architecture Deep Dive 03).

When another option wins. FOR UPDATE when the decision needs data a predicate cannot express. Optimistic versions for low-contention edits with user think time, such as the reservation version used by cancellation and modification.

Remaining risk. A conference night queues at roughly 200-500 allocations/s; lock_timeout and fail-fast 409s keep the queue from exhausting connections.

Stage 3 (Complete Design, Chapter 11) puts the invariant in a database transaction. A common alternative is a distributed lock (Redis, ZooKeeper) around the check-and-write.

Selection criteria. Whether the protected state lives in one database, and what happens when a lock holder pauses or crashes.

Choice for this workload. The database transaction, with no external lock. Holds, cursors and attempts already act as fences on their own rows.

When another option wins. Coordinating work that is not one transaction, such as one PMS consumer per hotel, uses a lease plus a fencing token; the per-hotel cursor compare-and-set is that token (Architecture Deep Dive 13).

Remaining risk. None for correctness; throughput limits are those of Decision 07.

Stage 4 (Complete Design, Chapter 12) faces a payment step that takes seconds to a minute while the last unit on a night can sell to someone else.

Selection criteria. Payment duration, scarcity of the night, and the abandonment rate (each abandon hides a unit for the TTL).

Choice for this workload. Hold first, 600 s TTL, one active hold per traveler per stay, explicit release when the traveler leaves, and expiry deferred while a payment is in flight (Architecture Deep Dive 04).

When another option wins. Immediate booking for instant payment methods on ample inventory, and for bookings with no online payment step (such as corporate billing), where allocating straight to confirmed is enough.

Remaining risk. Hold hoarding across accounts on scarce nights; rate limits per principal and per room-night bound it.

Stage 6 (Complete Design, Chapter 14) must order two systems that cannot share a transaction: the hold on the platform and the money at the provider.

Selection criteria. When the rate plan charges the card, which crash window the system prefers to repair, and how visible voids are to travelers.

Choice for this workload. Hold → attempt → authorize → capture → confirm for prepaid rates, and reconciliation is the cost of that choice (Complete Design, Chapter 15).

When another option wins. Authorize → confirm → capture for pay-at-hotel and deferred-capture rates. Authorize-first in markets where invalid payment methods dominate checkout traffic.

Remaining risk. Captured but not confirmed. Reconciliation confirms if the hold fence still matches, otherwise refunds; that state should stay near zero.

The booking API (Complete Design, Chapter 07) promises p95 ≤ 800 ms platform-side, but the provider call is bounded separately by auth_timeout = 60 s, and some payment methods complete only by redirect or webhook.

Selection criteria. The slowest supported payment method, client capabilities, and the need for retries to be safe.

Choice for this workload. Synchronous with the 202 fallback, made safe by the idempotency key (Architecture Deep Dive 05). The confirmation notification, driven by the outbox, is the backstop for clients that never come back.

When another option wins. Fully asynchronous confirmation when redirect or bank-transfer methods dominate.

Remaining risk. A traveler who closes the app mid-payment learns the outcome only by notification.

Stage 9 (Complete Design, Chapter 17) makes the hotel's PMS or channel manager a second writer, because the hotel also sells through other channels. When its report contradicts rooms the platform already sold, one side must win.

Selection criteria. The platform's share of the hotel's sales, sync latency and reliability, and contractual liability for an oversell.

Choice for this workload. Platform-authoritative. PMS batches carry absolute per-night values, a per-hotel cursor compare-and-set rejects stale or replayed batches, and a night reported below held + confirmed becomes a recorded conflict instead of an applied change (Architecture Deep Dive 13).

When another option wins. Allotments for hotels without real-time integration. Channel-manager-authoritative only where the platform is a minor channel and the hotel explicitly accepts liability for invalidated bookings.

Remaining risk. A cross-channel oversell window bounded by sync latency, resolved by the hotel (relocation or a PMS correction).

About 135 write transactions/s fit one primary, so Stage 10 (Complete Design, Chapter 18) shards for isolation, not throughput: a conference at one hotel should not slow every other hotel.

Selection criteria. Blast radius, hot-property isolation, and keeping every booking transaction on one shard.

Choice for this workload. A single primary until isolation is needed, then hotel_id sharding through a directory (Architecture Deep Dive 14).

When another option wins. Region-first partitioning when data residency demands it, with hotel_id sharding inside each region.

Remaining risk. Sharding does not help one hot room-night; cross-region replication keeps an RPO above zero.