Airbnb Search & Pricing Engine
Airbnb's search and pricing system: ranking algorithms, dynamic pricing, and personalized recommendations.
What is an Airbnb-style search and pricing engine?
An Airbnb-style search and pricing engine is the marketplace path that turns a guest's destination, dates, party size, filters, and preferences into an ordered set of homes with current availability and prices. Search retrieves nearby candidates and ranks them; pricing predicts useful host rates and produces the guest-visible quote.
In plain language, it must answer two questions quickly: Which homes are a good match? and What can this guest actually book for these dates and this total? The first answer may use cached and predicted data. The second must come from authoritative inventory and pricing services.
The core invariant is that ranking may be approximate, but a bookable result cannot invent availability or price. Search projections can be stale; the inventory authority must still approve the dates, and the pricing authority must issue a current, versioned quote.
This design exercise uses an assumed workload of 100 million searches per day and 7 million active listings. The numbers are inputs for architecture practice, not claims about current production traffic. The goal is to connect scale, geographic recall, freshness, personalization, and pricing consistency to user-visible behavior.
Define what search can promise
A marketplace serves guests, hosts, and the platform at once. Before choosing a database or model, state which decisions must be exact and which may be approximate. That boundary determines where caching, eventual consistency, and degraded modes are safe.
Functional
Guest actions
- Search by destination, viewport, dates, guests, and filters.
- Pan or zoom a map without losing a stable result contract.
- Inspect a ranked listing with available dates and a price total.
- Refresh or continue when availability or price changes.
Supply and pricing
Host actions
- Open or block nights and define stay constraints.
- Set a manual price or accept a recommendation policy.
- Apply minimums, maximums, discounts, and event rules.
- Observe demand signals without exposing another host's private data.
Non-functional
Service promises
- Keep regional search P95 below 200 ms for the exercise.
- Preserve useful geographic recall during ordinary peaks.
- Degrade personalization before availability or price correctness.
- Isolate a hot city, event, or failed region from the global marketplace.
Out of scope
First-version boundary
- No full booking, payment, refund, or fraud workflow.
- No claim of a globally optimal ranking for every stakeholder.
- No synchronous model training in the search request.
- No use of a ranking estimate as an authoritative checkout quote.
Four decisions shape the system
- Geographic semantics: support a destination, radius, or visible map bounds; define whether moving the map automatically reruns search.
- Availability semantics: retrieval may use a bounded-stale projection, but final result assembly and booking revalidate sellable nights.
- Personalization semantics: guest features improve order; a deterministic non-personalized fallback must still return valid results.
- Price semantics: recommendation models advise host rates, while the pricing authority owns host rules, fees, taxes, discounts, currency, and quote version.
Treat ranking score, availability decision, and price quote as three different data types. Combining them into one cached object makes it too easy for an approximate model output to cross an authority boundary.