Section 12: Forty Thousand Unique Things in One Bounding Box - Evolution II: Marketplace Search and Booking

Executive Summary: Section 11's per-listing calendar propagates into the two places the hotel design cannot follow — search, and the booking contract itself. With 40,000 candidate listings per bounding box and 4,500 searches per second at peak, filtering after retrieval costs 180 million document reads per second — the Section 3 arithmetic repeating one tier up. So the availability predicate moves into a geo-sharded index, ranking replaces sorting, and Request-to-Book holds a single-unit night for 24 hours rather than 10 minutes: 144x longer, a correctness problem wearing a product label. The transactional parts of the hotel design survived; the parts that broke encoded an assumption about the product.

The interviewer is not finished. "Fine — the inventory model is rebuilt. Now reuse your Marriott search stack on it: same index, same Redis availability layer, more documents. What goes wrong?"

Search Stops Being a Filter

At Marriott, search filters and then sorts. A guest in Miami metro gets 90 candidate properties (Section 8, Deep Dive: Scaling to a Hotel Chain), deliberately interchangeable within a brand and room type — that is the promise of a chain. Drop the sold-out ones, sort by price: the ordering is near-objective because the units are near-identical.

At Airbnb, a bounding box returns 40,000 candidate listings, no two the same object. No price sort is correct, because price is not comparable across non-comparable goods — and guests know it: the look-to-book ratio is 400 searches per booking against Marriott's 150, because browsing 30 unique homes is the shopping process.

"So rank them. Where's the architectural problem?"

In the arithmetic. Peak load is 4,500 search QPS, and the naive shape — retrieve the 40,000 geographic candidates, then ask the calendar store whether each is free for the requested nights — costs 40,000 x 4,500 = 180 million document reads per second. You have met its ancestor: Section 3, Scale Estimation & Workload Analysis, derived 25.8 million cell reads per second, and that is what forced a precomputed availability index at Marriott (D8). The lesson repeats one tier up with a sharper edge: there, availability sat beside the index as a Redis layer; here the predicate must go inside it.

Two commitments deserve defending aloud. The index is sharded by geography, not by listing id, because every query is a bounding box; an id-hashed index fans every search to every shard, multiplying 4,500 QPS by the shard count for nothing. Flip trigger: if a non-geographic query becomes primary — "any treehouse, anywhere, in October" — add a second index by attribute rather than reshuffling this one. And each listing's 365-day availability rides in the index as a bitmap derived from its calendar document (D12), so the predicate from Section 11, Evolution I: From Fungible Rooms to Unique Homes — nights free, min-stay satisfied, advance notice satisfied — is a bitwise AND where the candidate already sits. The rejected alternative, a query-time join against those documents, is the 180-million-read path with extra steps. D12's flip trigger applies underneath: a multi-unit B&B reverts to the counter, and its bitmap becomes a count. D7 is unchanged: the index may be seconds stale, survivable only because the hold re-validates in-transaction. The index may be wrong; the commit may not.

Key Insight: Ranking is what you do after the predicate has shrunk the candidate set, never instead of it. A ranker over 40,000 documents per query is a cost problem; a ranker over the bookable remainder — personalised last, where the set is smallest — is a product.

Quick check before moving on: