Section 8: The Part That Didn't Have to Change - Deep Dive: Scaling to a Hotel Chain

Executive Summary: The Marlin Bay becomes 8,500 Marriott properties, and the surprise is how little of Section 7 needs rewriting. A booking touches only one property's rows, so the write path shards perfectly on property_id — 28 peak writes per second over any number of shards, no distributed transaction anywhere. What breaks is search: 6,300 inventory cells per city query times 4,100 peak QPS is 25.8 million cell reads per second. We build the three-layer index that answers it, state its staleness contract honestly, and meet the chain-only problem candidates never anticipate: channels holding their own copy of availability.

"Now roll it out across Marriott — nine thousand properties, thirty brands, every country. Same rule: nobody is ever sold a room that doesn't exist." Resist the reflex to start over; open with the claim you earned in Section 3:

"Most of this doesn't change. The inventory model stays — a counter per (property, room_type, date) — and so do the transaction, the hold and the saga. The reason is structural: a booking only ever decrements rows belonging to one property. Dana's three suite-nights at the Marlin Bay never touch a row in Denver. So the write path shards on property_id, and the chain's whole booking load is 5.5 writes per second average, 28 at peak. What breaks is search."

What Shards Perfectly, and Why

The transaction boundary and the sharding boundary are the same boundary here, drawn by the business, not by us — keying inventory by date or by room type would have split one booking across shards and dragged two-phase commit into a 28-writes-per-second workload. Stage B's booking tier is therefore Stage A's, replicated: Postgres shards homed by property, each with its own inventory, holds, bookings and outbox tables, running Section 7's conditional decrement in ascending stay_date order. D3's flip trigger is unchanged and still far away — we abandon Postgres above roughly 50,000 booking writes per second.

Key Insight: Scaling a booking system is not a write-scaling problem in disguise. The oversell rule everyone fixates on is enforced inside one property's rows, so it gets easier per shard as the chain grows.

Quick check before moving on: