Marketplaces & booking
Hotel booking - selling a range, on purpose, slightly twice
nights, holds, overbooking, cancellation
What this board gets wrong on purpose
The tension
Overbooking is a priced business decision and the board draws it as a component, which is the honest version - but the percentage is computed from historical no-show rates, and the third party pushing the most inventory changes into this system is a channel manager whose availability view is seconds to minutes behind ours. So the overbooking margin is stacked on top of a synchronisation lag of unknown size, and the two failure modes are indistinguishable from the outside: a night that oversells because the policy said 103% and a night that oversells because Expedia sold a room we had already sold both end with a guest in the lobby at 23:00. Nothing on this board can tell the operator which one happened. The cancellation window is the second unresolved edge: free_cancel_until is stored in the property timezone and evaluated by a worker running in UTC, so every daylight-saving boundary is an hour in which the system charges people it should not and refunds people it should.
1 · Requirements
The unit of sale is a room-night. The unit of purchase is a stay. Almost everything difficult here comes from that mismatch.
Ask these before designing
- Are we the hotel or the agency? If we own the inventory we are the source of truth. If we are an OTA, we hold a cached copy of somebody else’s truth and every guarantee weakens accordingly. This board assumes we own it and also sell through agencies, which is the hardest of the three.
- Is overbooking allowed, and who owns the number? It is a revenue-management decision with a cost line for walking guests. If the answer is "no", occupancy drops by 4-8% and somebody will ask why.
- Do we hold inventory during checkout? For a 2-minute booking flow, a hold is often not worth the complexity; for a flow with an approval step, it is essential.
- Whose timezone is the cancellation deadline in? The property’s, always - but the worker that enforces it runs in UTC, and that gap is a real bug twice a year.
- Rate plans: how many, and do they restrict? Minimum stay, closed-to-arrival and non-refundable are not pricing, they are availability, and they belong in the search path.
- What is the booking horizon? 500 days sets the size of the inventory table exactly.
Functional
- Search availability for a date range, a party size and a set of filters.
- Book a stay: all nights or none.
- Apply rate-plan restrictions (min-stay, closed-to-arrival) at search time, not at booking time.
- Modify or cancel, applying the property’s cancellation policy and charging the penalty.
- Accept inventory and rate updates from channel managers, and push our availability back to them.
- Support a deliberate overbooking margin per property, per season.
Non-functional
- Search p95 under 400 ms across 50 properties x 20 room types x 3 nights - 3,000 inventory rows per query, which is why search reads a precomputed model and never the transactional table.
- Booking is strongly consistent. All nights commit together or the booking fails.
- Search availability 99.99%, degrading to a stale read model rather than an error.
- Booking availability 99.95%, failing closed.
- Channel updates applied within 60 s at p99. Beyond that, the agency is selling rooms against a view we know is wrong.
Explicitly out of scope
Dynamic pricing and revenue management models, loyalty programmes, housekeeping and room assignment, property onboarding, payments compliance.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, an 8-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 8walkthrough steps
- 5tables34 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Two-sided systems where inventory must not be sold twice.