Marketplaces & booking
Rental search - availability is a calendar, not a column
How a stay search filters by place, dates and price at once, and why the availability calendar is the bottleneck.
What this board gets wrong on purpose
The tension
The availability bitmap in the index is about 90 seconds behind our own calendar, which is fine - booking re-checks every night under a lock. The problem is the calendar itself is hours behind reality for any listing that is also on another site: iCal imports are polled every three hours, so a night sold on the other platform at 10:00 is still AVAILABLE in our calendar at 12:59, the booking re-check passes, and the double booking is invisible to us until the host cancels on the guest. Nothing here can close that window without the other site pushing to us, and it does not. The bitmap also answers only "free on these nights" - minimum-stay and check-in-day rules are evaluated after the AND, on the candidates that survived it, so a listing with a 7-night minimum passes a 3-night mask and is dropped late, and a search near a holiday can lose a third of its first page to that second pass and come back short.
Practise this as an interview
Take Rental search - availability is a calendar, not a column as a timed system design interview on a blank board - on your own, with the requirements to check yourself against, or with a candidate you invite.
Start here
Why this design
A rental marketplace is a search engine whose most important filter changes every time somebody books anything. Place is a geo index; guests and amenities are columns; but availability is a property of individual nights on a calendar, and price is the sum of those nights. Interviewers use it to see whether you can keep a per-night calendar inside a search index cheaply - and whether you notice who else writes to that calendar.
What you will learn
- Why "available 12-15 March" is three bits, not a column, and why the whole calendar fits in 46 bytes.
- Why the filters run in order place, dates, price, rank, each on fewer candidates than the last.
- Why a price filter needs nightly prices in the index, because the total is different for every range.
- Why search may be 90 seconds stale while booking must re-check every night under a lock.
- Why the hardest writer to the calendar is another website, polled every three hours.
- Why minimum-stay rules are a second pass after the bitmap, and what that costs a search page.
How to read this board
- Press play once: the walkthrough follows one search to one booking, then one calendar edit back into the index.
- SEARCH: the pipeline along the top.
- THE CALENDAR: the source of truth and its three writers.
- DATA MODEL: one row per listing per night, and the imported calendars.
- Then pages 1 to 6 in order: requirements, capacity, storage, availability, how it works, deployment.
1 · Requirements
A guest describes a stay; the system must find every listing that can host exactly that stay, at a price they will pay, fast enough that dragging the map feels live.
Ask these before designing
- Is the result exact or best-effort? Search showing a listing that turns out to be booked is recoverable; booking a night twice is not. This board makes search approximate and booking exact.
- Is price filtered on the nightly rate or the total? Guests think in totals with fees. Totals depend on the range, so the index needs per-night prices.
- Are listings on other sites too? Most professional hosts are. Then our calendar imports theirs, and the import interval is an availability bug of that many hours.
- Which stay rules exist? Minimum nights, maximum nights, allowed check-in days, preparation days between stays. Each is an availability rule disguised as a setting.
- How far ahead can you book? 365 days sets the bitmap at 365 bits.
Functional
- Search by map bounds or place name, check-in and check-out, guest count, price range and amenities.
- Results ranked, with the total price for the stay shown on every card.
- Hosts edit availability and nightly price per night, and set stay rules.
- Hosts connect external calendars (iCal) that block nights here.
- Book a stay: every night must be free at the moment of booking.
Non-functional
- Search p95 under 300 ms, including map drags, at 5,800 searches/s peak.
- Index freshness p99 under 2 minutes after a calendar change we receive.
- No double booking from our own sales - enforced by the database, not by search.
- Search availability 99.95%; it may serve a slightly stale index rather than fail.
- Booking availability 99.95%, failing closed.
Out of scope
Payments and payouts, reviews, messaging, pricing suggestions for hosts, fraud and trust, photos and their CDN.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, a 7-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 7walkthrough steps
- 5tables38 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.
- Checkout - holding stock you have not sold yet
- Auction bidding - the clock is part of the system
- Food delivery - three parties and a promise
- Hotel booking - selling a range, on purpose, slightly twice
- Seat sales - fifty thousand people, one hundred seats
- Coupon codes - redeemable once, by anyone, at the same moment
- Job board - search, apply, and the recruiter's inbox