Airbnb Stays Marketplace.

How Do You Show a Family Only the Homes That Are Free, and Pay a Host You've Never Met?

It is a Tuesday night in Bengaluru, three weeks before the Diwali long weekend. Rohan Iyer has promised his parents, his wife and their two children three nights in Goa. He opens the app, types "North Goa", picks Friday to Monday, five guests, and drags the map over Assagao. Every pin he sees must be a home that is actually free for those three nights, at a price for those three nights, and the dozen pins on his screen have to be the dozen he is most likely to book out of the thousands in that rectangle.

Two hundred metres from where his thumb stops, Meera Fernandes runs a three-bedroom homestay in an old Portuguese-era house. She lists it on Airbnb and on two other travel sites, and the only thing joining the three calendars is a link to a calendar file each site reads every few hours. Her nightly price moves with demand while she sleeps. When Rohan pays in rupees, the money won't reach Meera until the business day after his family walks through her door, and a guest from London who stayed last week paid in pounds for the same rooms. If anything in this chain is wrong, a family arrives to a house that is already full, or a host is paid twice, or not at all.

This is the system we'll design today.

The Interview Begins#

You're interviewing at a company that runs a travel marketplace. The interviewer shares a screenshot: a map of North Goa with eighteen price pins, a calendar with three nights greyed out, and a payout screen that says "Expected Monday, 9 November".

Your Questions#

Functional Requirements#

Non-Functional Requirements#

Search Estimation#

Availability and Price Index#

Calendars, Pricing and Money#

Key Metrics Summary#

System Architecture#

%% title: A stays marketplace: search reads, everything else streams in
flowchart TD
  subgraph L1["Layer 1 · Guests and hosts"]
    direction LR
    GUEST@{ icon: "sd:phone", label: "Guest app<br/>map, dates, guests" }
    HOST@{ icon: "sd:laptop", label: "Host tools<br/>calendar, price range" }
    EXT@{ icon: "sd:globe", label: "Other travel sites<br/>.ics feeds" }
  end
  subgraph L2["Layer 2 · Read path"]
    direction LR
    API@{ icon: "sd:api", label: "API gateway" }
    ROOT["Search root<br/>fan out, merge, re-rank, pins"]:::hot
    LEAF["Search leaves<br/>geo + dates + retrieval + ranker"]:::core
  end
  subgraph L3["Layer 3 · Sources of truth"]
    direction LR
    CAL["Calendar service<br/>nights, blocks, rules"]:::service
    ICAL@{ icon: "sd:cron", label: "iCal poller<br/>import every few hours" }
    PRICE@{ icon: "tech:spark", label: "Smart Pricing<br/>Spark batch + demand" }
    RES["Reservations<br/>one row per stay"]:::service
  end
  subgraph L4["Layer 4 · Events and money"]
    direction LR
    BUS@{ icon: "tech:kafka", label: "Kafka<br/>listing changes, bookings" }
    PAY["Payments<br/>pay-in, ledger, payouts"]:::core
    RISK@{ icon: "sd:shield", label: "Risk scoring<br/>at booking" }
  end
  GUEST ==> API ==> ROOT
  ROOT ==> LEAF
  HOST --> CAL
  EXT -.->|"fetched"| ICAL --> CAL
  PRICE --> CAL
  CAL --> BUS
  BUS ==>|"~10,000 updates/s"| LEAF
  API --> RES
  RES --> RISK
  RES --> PAY
  RES --> CAL
  class GUEST,HOST client
  class EXT external
  class API edge
  class BUS queue
  class ICAL,PRICE service
  class RISK service

KEY INSIGHTS:

• Search reads, it never asks. Location, availability, prices and rules for every listing live in the search leaves' memory, updated by events. A search doesn't call the calendar or pricing services
• Each source of truth owns one thing. The calendar service owns nights, pricing owns suggestions, reservations own stays, payments own money; they talk through events, so one can be slow without stopping the others
• Money runs on its own clock. A booking creates obligations; the ledger and payout scheduler turn them into money movements days or weeks later

The One Strict Write, Briefly#

Data Flow: Rohan Searches, Then Books#

%% title: Rohan drags the map, then reserves Meera's home
sequenceDiagram
  autonumber
  participant R as Rohan's app
  participant S as Search root
  participant L as Leaves, North Goa
  participant B as Reservations
  participant K as Risk scoring
  participant P as Payments
  R->>S: Map rectangle, 6–9 Nov, 5 guests
  S->>L: Fan out to every leaf
  L-->>S: Top results: free all 3 nights, total price
  S-->>R: 18 cards, 11 full pins, 7 mini-pins
  R->>B: Reserve Meera's home, quote id
  B->>K: Score this booking
  K-->>B: Low risk, no friction
  B->>B: Insert 3 nights, unique per listing-night
  B->>P: Charge ₹38,400, hold until check-in
  P-->>R: Confirmed, payout to Meera on 9 Nov

MEANWHILE, IN PARALLEL:

• The reservation emits NightsBooked; the indexer clears those three bits in the leaf that holds Meera's listing within seconds, and her exported .ics feed is regenerated for the other sites to fetch
• A review window for both Rohan and Meera is scheduled to open at check-out on 9 November

Deep Dive 1: Geo Search With Dates at Query Time (Week 7 Concepts: Search Architecture; Week 1: Partitioning)#

This builds on Week 7, Day 1 · Search Fundamentals and Architecture and Week 1, Day 1 · Partitioning Deep-Dive.

What is published: Airbnb's search architecture is a root that fans out to leaf services, which do retrieval and ranking. Its retrieval paper notes that "almost all searches on Airbnb contain some type of filtering criteria (most commonly a geographic region filter if a user moves the map area)", that flexible dates of ±3 days create 49 check-in and check-out combinations, and that it built "a compact data structure of pre-computed availability and pricing" for a fixed number of days ahead, updated in near real time, with a final step that refreshes "accurate pricing and availability checks" before results leave the leaf.

• Partition by listing, not by place. If leaves were split by region, Goa during a festival would melt one shard while others idle. Spreading listings evenly (by listing id) across leaves and fanning every search out to all of them keeps load even; the geo filter runs inside each leaf. Add replicas of the whole leaf set to add throughput.
• Count before you draw. A rectangle over all of France holds hundreds of thousands of homes. The leaf caps how many candidates it passes on (by a cheap prior, such as recent booking rate) so the ranker's cost is bounded per leaf.
• Freshness has a budget. An indexer consumes listing events (prices, blocks, bookings) and applies them to the leaf holding that listing, a few microseconds each: 10,000 a second is nothing for memory, everything for correctness. Track "event time to searchable" as a metric; target about a minute at p99.
• Search may be slightly stale; booking isn't. A home booked a second ago can still appear. The reservation's unique key catches it, and the guest sees "just booked". Measure that rate; it is the cost of fast search.

# search/leaf_filter.py

"""
The cheap filters in a search leaf (illustrative). Every listing in memory has a
geo cell, a 365-night availability bit array (bit set = free), nightly prices and
stay rules. Survivors of where + when + rules go on to retrieval and ranking.
"""

from dataclasses import dataclass


@dataclass
class Listing:
    lid: int
    cell: int
    free: int               # bit i set = night (today + i) is free
    prices: list            # nightly price in listing currency, 365 entries
    min_nights: int
    max_guests: int
    checkin_days: set       # allowed weekdays, 0 = Monday
    cleaning_fee: int


def stay_mask(start: int, nights: int) -> int:
    return ((1 << nights) - 1) << start


def eligible(l: Listing, cells: set, start: int, nights: int, weekday: int, guests: int) -> bool:
    if l.cell not in cells or guests > l.max_guests:
        return False
    if nights < l.min_nights or weekday not in l.checkin_days:
        return False
    m = stay_mask(start, nights)
    return l.free & m == m                                  # free on every night of the stay


def total(l: Listing, start: int, nights: int) -> int:
    return sum(l.prices[start:start + nights]) + l.cleaning_fee


def search_leaf(listings, cells, start, nights, weekday, guests, cap=5000):
    out = [(l.lid, total(l, start, nights)) for l in listings
           if eligible(l, cells, start, nights, weekday, guests)]
    return out[:cap]                                         # bounded work for the ranker

Deep Dive 2: Retrieve, Then Rank, Then Choose the Pins (Week 7 Concepts: Query Processing and Relevance)#

This builds on Week 7, Day 3 · Query Processing and Relevance.

What is published: Airbnb moved search ranking from gradient-boosted trees to neural networks (KDD 2019). Its 2018 work learned 32-dimensional embeddings for 4.5 million active listings from 800 million search click sessions, for real-time personalization and similar-listing recommendations, which it said drive 99% of conversions. Its embedding-based retrieval (2026) uses a two-tower model whose listing tower is computed daily offline; it chose an inverted-file (IVF) index over HNSW because HNSW's memory grew too large under real-time updates and performed poorly with filters, and stores each listing's cluster id in the search index so retrieval is "a standard search filter". Euclidean distance gave balanced clusters where dot product didn't. The launches added 0.31% to booking conversion and cut compute by about 16%. For maps (KDD 2024), a "bookability filter" that drops pins far less likely to be booked than the top one raised uncancelled bookings by 1.9% in a test of 34 million searchers per arm; on desktop, where all 18 cards need pins, "mini-pins" without prices get about 8 times fewer clicks.

%% title: The ranking funnel, each stage an order of magnitude smaller
flowchart TD
  F["Filtered by place, dates, rules<br/>~20,000 free homes"]:::service
  EBR["Retrieval · two towers, IVF clusters<br/>keep ~1,000"]:::core
  DNN["First-stage ranker · deep model<br/>booking probability"]:::core
  SET["Setwise re-ranker at the root<br/>top ~100 as a page"]:::hot
  PINS["Pins · bookability filter<br/>full pins, mini-pins"]:::ok
  EMB@{ icon: "sd:ml", label: "Listing vectors<br/>rebuilt daily offline" }
  F ==> EBR ==> DNN ==> SET ==> PINS
  EMB -.-> EBR
  class EMB store

• Daily vectors, live facts. The listing tower can't use today's price, because it runs once a day. Retrieval uses yesterday's price features; the leaf's live prices and availability from Deep Dive 1 are applied before anything is shown. A stale vector only costs a little ranking quality, never a wrong price.
• The query tower runs per request on the place, dates, party size and length of stay: one small inference, not one per listing.
• IVF fits a filtered index. Cluster ids are just another field in the leaf; "nearest 8 clusters to this query" becomes a filter alongside the geo cells and availability. A graph index like HNSW would have to be updated thousands of times a second and searched around filters.
• Train on trips, not single searches. A guest searches for weeks before booking. Airbnb's retrieval model treats the booked listing as the positive and homes the same guest saw or wishlisted on that trip, but didn't book, as hard negatives. Random negatives made the problem "too easy".
• The re-ranker sees the page. Eighteen near-identical villas at the same price is a worse page than a mix. A setwise model scores the set, which a per-listing model can't.

# search/pins.py

"""
Choosing map pins (illustrative), after Airbnb's published "bookability filter":
attention on a map is spread across pins, so a pin far less likely to be booked
than the best one costs the guest a click. Listings below the threshold become
mini-pins on desktop (where every card needs a pin) or are left off on mobile.
"""

ALPHA = 1.0     # how far below the anchor's booking probability a full pin may fall (log scale)


def choose_pins(ranked: list, desktop: bool, max_pins: int = 18):
    """ranked: [(listing_id, p_book)] best first. Returns (full_pins, mini_pins)."""
    top = ranked[:max_pins]
    if not top:
        return [], []
    anchor = top[1][1] if len(top) > 1 else top[0][1]     # second-best: robust to one outlier
    full, mini = [], []
    for lid, p in top:
        if p * (10 ** ALPHA) >= anchor:
            full.append(lid)
        elif desktop:
            mini.append(lid)                               # still shown, drawn small, no price
    return full, mini

Deep Dive 3: Calendars That Other Websites Also Write (Week 5 Concepts: Conflict Resolution; Week 2: Distributed Cron)#

This builds on Week 5, Day 4 · Conflict Resolution and Week 2, Day 5 · Distributed Cron and Job Scheduling.

What is published: Airbnb's help centre says an imported calendar "automatically updates every 3 hours", that a host can select Refresh to check sooner, that only links ending in .ics work, and that nights blocked or booked on Airbnb are blocked on the other site's calendar through the export link. The format itself is iCalendar (RFC 5545), where each busy period is an event with a stable UID.

%% title: Importing and exporting calendars without trusting the file
flowchart TD
  OTHER@{ icon: "sd:globe", label: "Other site<br/>.ics feed" }
  SCHED@{ icon: "sd:cron", label: "Poll scheduler<br/>due feeds first" }
  FETCH["Fetcher<br/>If-None-Match, timeout"]:::service
  DIFF["Snapshot diff<br/>per source, sanity checks"]:::core
  CAL["Calendar service<br/>blocks tagged by source"]:::hot
  EXP@{ icon: "sd:cdn", label: "Our .ics export<br/>rebuilt on change" }
  SCHED ==> FETCH
  OTHER -.->|"304 or new file"| FETCH
  FETCH ==> DIFF ==> CAL
  CAL ==> EXP
  EXP -.->|"fetched by them"| OTHER
  class OTHER external
  class SCHED service
  class EXP edge

• Tag every block with its source. A block imported from feed F is replaced only by the next good snapshot of F. It can never erase an Airbnb reservation or a host's manual block, and two feeds can't overwrite each other. Diff by event UID and date range, not by "the whole calendar".
• Poll by risk, not round-robin. The cost of staleness is concentrated: a listing with free nights in the next few weeks, on dates people are searching, whose feed changed recently. Score each feed by that and poll the riskiest every few minutes, the rest on the slow cycle. ~370 fetches a second at 3 hours is the floor, not the ceiling.
• Conditional requests make frequent polling cheap. Send the last ETag or Last-Modified; most fetches return 304 with no body. Respect each site's rate limits and back off per host name, not globally.
• Fetch on intent. The Reserve button is the one moment staleness turns into a double booking. A synchronous refresh capped at ~1 second covers it; if the other site doesn't answer, book anyway and flag the stay for the host to confirm, rather than failing the guest.
• Our export is somebody else's poll. Rebuild Meera's .ics within seconds of a booking and serve it from a CDN with a short cache time; then the other site's blind window is its own poll interval, not ours plus theirs.
• Where partners offer an API that pushes changes, use it instead of iCal; that is a different integration with its own ordering problems, and this design treats iCal as the fallback every host can use.

# calendar/ical_import.py

"""
Applying one imported .ics snapshot (illustrative). Blocks are tagged with their
source feed; a snapshot replaces only that feed's blocks, never reservations or
manual blocks; suspicious snapshots are held back instead of unblocking nights.
"""

MAX_DROP = 0.5          # a snapshot that frees over half the feed's blocked nights needs a second look


class SuspiciousFeed(Exception):
    pass


def apply_snapshot(cal, listing_id: int, feed_id: str, events: list, confirmed_drop: bool = False):
    """events: [(uid, first_night, last_night)] parsed from the feed (end date exclusive in .ics)."""
    new = {(uid, d) for uid, a, b in events for d in cal.nights(a, b)}
    old = cal.blocks(listing_id, source=feed_id)                     # {(uid, night)}
    if not events and old:
        raise SuspiciousFeed("empty feed: keep the last good snapshot")
    freed = {n for _, n in old} - {n for _, n in new}
    if old and len(freed) > MAX_DROP * len({n for _, n in old}) and not confirmed_drop:
        raise SuspiciousFeed("large drop: confirm on the next fetch before unblocking")
    with cal.tx(listing_id):
        for uid, night in new - old:
            cal.block(listing_id, night, source=feed_id, uid=uid)    # a clash with our own stay is flagged
        for uid, night in old - new:
            cal.unblock(listing_id, night, source=feed_id, uid=uid)  # only this feed's blocks
    cal.emit_changes(listing_id)                                     # to the search indexer

Deep Dive 4: Smart Pricing, a Suggestion With Guardrails (Week 8 Concepts: Streaming vs Batch)#

This builds on Week 8, Day 2 · Streaming vs Batch Processing.

What is published: Airbnb's pricing paper (KDD 2018) describes three components: a classifier that predicts "the booking probability of each listing-night", a regression model that predicts the optimal price for each listing-night with a customised loss, and personalization logic on top, deployed to power Price Tips and Smart Pricing. It notes there are no "identical" products on Airbnb, which makes conventional demand-curve pricing very difficult. Airbnb's help centre says Smart Pricing "uses hundreds of factors about your listing and your area to adjust your nightly price based on demand", within a minimum and maximum the host sets.

%% title: Smart Pricing: a batch model, a fast path and guardrails
flowchart TD
  LOGS@{ icon: "sd:database", label: "Searches, views, bookings<br/>by area and date" }
  BATCH@{ icon: "tech:spark", label: "Spark nightly batch<br/>3.3B listing-nights" }
  DEM["Demand monitor<br/>area-date spikes"]:::service
  MODEL["Booking probability<br/>then price strategy"]:::core
  GUARD["Guardrails<br/>host min-max, step limit, open quotes"]:::hot
  CAL["Calendar service<br/>nightly price"]:::service
  LOGS ==> BATCH ==> MODEL
  LOGS -.-> DEM -.->|"re-price these nights"| MODEL
  MODEL ==> GUARD ==> CAL
  class LOGS store

• Price from probability. For a listing-night, estimate P(booked | price, lead time, demand); the strategy model picks a price that trades a lower chance of booking against a higher price. Far ahead, with time to sell, it can ask more; close in with the night still free, less.
• Batch is the backbone. 3.3 billion listing-nights once a day is a few hours on a cluster, and most nights don't need more. The fast path re-prices only the slices where demand moved: a festival announced, a long weekend filling up.
• Every price change is a search update. Prices are the bulk of the ~10,000 updates a second. Rate-limit per listing (no night changes more than a few times a day) so the index and the host's calendar don't churn.
• Hosts must trust it. Show the suggestion and why ("demand for your area on these dates is high"); never cross the host's limits; let them pin a price on any night.
• Evaluate offline before A/B. Airbnb describes new offline metrics for pricing; the general idea is to check suggested prices against what actually booked, and at what price, before a host ever sees them.

# pricing/guardrails.py

"""
Turning a model's suggested nightly price into the price a listing shows
(illustrative). The model proposes; the host's range, a per-update step limit
and open guest quotes decide what is actually applied.
"""

MAX_STEP = 0.15         # at most ±15% per update for one night


def apply_suggestion(night, suggested: float, host_min: float, host_max: float,
                     current: float, open_quotes: int, pinned: bool) -> float:
    if pinned:
        return current                                   # the host set this night by hand
    if open_quotes > 0:
        return current                                   # a guest is checking out at this price
    target = min(max(suggested, host_min), host_max)     # never outside the host's range
    lo, hi = current * (1 - MAX_STEP), current * (1 + MAX_STEP)
    return round(min(max(target, lo), hi))               # move gradually toward the target


# Meera, 7 Nov: model says 19,000; range 9,000-16,000; today 11,000
# apply_suggestion(n, 19000, 9000, 16000, 11000, 0, False) -> 12650, then 14547, then 16000

Deep Dive 5: Payments as a Marketplace: Hold, Ledger, Pay Out (Week 2 Concepts: Idempotency; Week 3: Audit Logs)#

This builds on Week 2, Day 2 · Idempotency in Practice and Week 3, Day 5 · Audit Log System.

What is published: Airbnb's 10-K says it holds "the total amount the guest has paid until check-in", then recognises its service fee and starts the payout, which "generally occurs on the business day after the scheduled check-in", in about 50 currencies; it held $6.9 billion of such cash at the end of 2025. Its engineering blog describes a payments platform split into subdomains including Pay-in, Payout, Processing, Ledger, and Settlement and Reconciliation, and 20+ local payment methods added in 14 months, some confirmed asynchronously by webhook after the guest pays in another app. Its idempotency library, Orpheus (2019), splits each payment request into pre-RPC, RPC and post-RPC phases, with no service calls in the pre- and post-RPC phases and no database work during the RPC, reads idempotency state from the primary database, and classifies failures as retryable or not.

%% title: Money in, held, then out: every step a balanced ledger entry
flowchart TD
  G@{ icon: "sd:card", label: "Rohan pays<br/>card or local method" }
  PSP@{ icon: "sd:bank", label: "Payment provider<br/>settles in 1–2 days" }
  PAYIN["Pay-in<br/>idempotent charge"]:::service
  LED["Ledger<br/>double entry, append-only"]:::hot
  HOLD@{ icon: "sd:wallet", label: "Funds held for hosts<br/>a liability until check-in" }
  SCHED@{ icon: "sd:cron", label: "Payout scheduler<br/>business day after check-in" }
  OUT["Payout<br/>idempotent per payout id"]:::core
  M@{ icon: "sd:bank", label: "Meera's bank<br/>in rupees" }
  G ==> PAYIN ==> PSP
  PAYIN ==> LED
  LED --> HOLD
  SCHED ==> OUT ==> M
  OUT ==> LED
  class G client
  class PSP,M external
  class HOLD store
  class SCHED service

• The ledger is append-only. A refund or a changed booking is new entries that reverse or adjust, never an edit. The balance of any account at any time is a sum, and auditors can replay it.
• Three phases per external call. Before the call, write the intent and its key in one local transaction; make the call with nothing else open; after it, record the result. A crash between phases leaves a row that a retry can resume from, and a retry never re-sends money the provider has already accepted.
• Async payment methods wait in a state. A guest who pays in a wallet app is PAYMENT_PENDING until the provider's webhook arrives; webhooks are deduplicated by event id, and a sweeper asks the provider about any payment pending too long.
• Reconcile against the outside world daily. Provider settlement files and bank statements are matched, line by line, to ledger entries. Anything unmatched is a ticket, not a rounding error.
• Payouts are batched per host per day and per payout method. 365,000 a day is small; the care goes into country calendars, payout-method failures (a closed bank account moves the money back to "payable", not into the void) and tax withholding rules.

# payments/ledger.py

"""
A double-entry ledger and an idempotent payout (illustrative). Every posting is
a set of entries in one currency that sums to zero; postings are append-only and
keyed so a retried event can't post twice.
"""

from decimal import Decimal


class Unbalanced(Exception):
    pass


def post(db, key: str, currency: str, entries: list) -> None:
    """entries: [(account, amount)], positive = debit, negative = credit."""
    if sum(Decimal(a) for _, a in entries) != 0:
        raise Unbalanced(key)
    with db.tx():
        if db.exists("postings", key=key):
            return                                       # the same event, delivered again
        db.insert("postings", key=key, currency=currency)
        for account, amount in entries:
            db.insert("entries", posting=key, account=account, amount=Decimal(amount))


def pay_out(db, provider, host_id: str, stay_id: str, amount: Decimal, currency: str):
    key = f"payout:{stay_id}"
    row = db.primary.get("payouts", key=key)             # read the primary, never a replica
    if row and row.status in ("SENT", "CONFIRMED"):
        return row                                       # retried after a crash: already done
    if not row:
        db.primary.insert("payouts", key=key, host=host_id, amount=amount, status="INTENT")
    result = provider.send(idempotency_key=key, to=host_id, amount=amount, currency=currency)
    status = "SENT" if result.ok else ("INTENT" if result.retryable else "FAILED")
    db.primary.update("payouts", key=key, status=status, ref=result.ref)
    if result.ok:
        post(db, key, currency, [(f"payable:{host_id}", amount), ("cash:payouts_in_transit", -amount)])
    return db.primary.get("payouts", key=key)

Deep Dive 6: Risk Scoring at Booking and Two-Sided Blind Reviews (Week 9 Concepts: Security Architecture)#

This builds on Week 9, Day 5 · Security Architecture.

What is published: Airbnb's 10-K lists "host and guest reviews, account protection, risk scoring, secure payments", "fraud and scam prevention" and "anti-party technology" among the components of its system of trust. Airbnb's trust team wrote in 2018 about "targeted friction" against chargebacks, such as micro-authorisations, 3-D Secure and billing-statement verification, chosen by comparing the cost of false positives with fraud losses, which Airbnb absorbs rather than passing to hosts. In 2014 Airbnb changed reviews so that neither side sees the other's review until both have written one or the 14-day window, shortened from 30 days, has passed.

%% title: A stay's two reviews, sealed until both are in or 14 days pass
stateDiagram-v2
  [*] --> WINDOW_OPEN: check-out
  WINDOW_OPEN --> ONE_SEALED: first review submitted
  ONE_SEALED --> REVEALED: second review submitted
  ONE_SEALED --> REVEALED: 14 days pass
  WINDOW_OPEN --> CLOSED_EMPTY: 14 days, no reviews
  REVEALED --> [*]
  CLOSED_EMPTY --> [*]
  class REVEALED ok
  class ONE_SEALED queue

• Score, then decide with friction. A booking from a three-day-old account, with a card from one country and a device in another, for one night on New Year's Eve, four hours ahead, scores high. Low scores pass; middle scores get friction a real cardholder clears and a fraudster can't (micro-authorisations, 3-D Secure, ID verification); high scores are blocked or reviewed.
• Set the threshold by cost. A false positive loses a real booking; a false negative becomes a chargeback the platform pays. Pick the cut-off that minimises the sum, per market and night.
• Party risk is its own signal. A last-minute, one-night, whole-home booking on New Year's Eve by a new account is a different risk from a stolen card; require more history for it.
• Why blind reviews: if Rohan reviews the broken hot water first, Meera can read it and retaliate about the messy kitchen, so both hold back. Sealing both until both are in, or 14 days pass, means neither can react to the other.
• Scoring sits on the booking path, so it has a hard latency budget and a fallback: if the model service is slow, apply a conservative rule set rather than block every booking or wave every booking through.
• Features are precomputed. Account age, past chargebacks, device history and velocity counters are kept in a feature store updated by events; at booking, the model reads a few keys and runs.
• Friction is a state, not a failure. The reservation waits in VERIFYING while the guest completes the challenge; the nights are held by the reservation row from Phase 3, with a short timeout.
• The reveal is a durable timer. At check-out, schedule a reveal job for check-out + 14 days; submitting the second review triggers it early. The job is idempotent (reveal twice = reveal once), and after reveal neither review can be edited.
• Ratings feed search. A revealed review updates the listing's rating and review count, which arrive in the search leaves as one more listing event.

# trust/booking_risk.py

"""
Risk decision at booking (illustrative). A model score plus a fallback rule set;
the cut-offs come from the expected cost of a wrong decision, so a high-value
night with a new account gets friction sooner than a routine stay.
"""

CHARGEBACK_COST = 1.0      # cost per unit of booking value if fraud gets through
FRICTION_LOSS = 0.08       # share of good guests who abandon at a challenge (assumed)


def decide(score: float, value: float, model_ok: bool, rules) -> str:
    if not model_ok:
        return rules.fallback()                          # never fail open or closed on a timeout
    expected_fraud = score * value * CHARGEBACK_COST
    expected_friction = (1 - score) * value * FRICTION_LOSS
    if score > 0.9:
        return "BLOCK"
    if expected_fraud > expected_friction:
        return "FRICTION"                                # micro-auth, 3-D Secure or ID check
    return "ALLOW"

Data infrastructure, briefly: every deep dive above leans on the same events (searches, views, bookings, prices, reviews) landing in a warehouse for training and evaluation. Airbnb built Minerva so that a metric like nights booked is defined once and computed the same way for dashboards and experiments; whichever tool you use, define the marketplace's core metrics in one place, or ranking and pricing teams will argue from different numbers.

Meera's Diwali Weekend#

Edge Cases#

Monitoring Dashboard#

SLOs for the Marketplace#

The interviewer leans back. "One more."

Summary: Concepts Applied from 10-Week Course#

Why Airbnb Matters#

Self-Assessment Checklist#

After studying this case study, you should be able to:

Search and ranking:

Calendars and pricing:

Money and trust:

Sources#

Airbnb:

• Book

  Airbnb — About us (9M+ active listings, 150K+ cities and towns, 220+ countries and regions, 2.5B+ guest arrivals, 5.5M+ hosts, $380B+ earned by hosts; last updated May 2026): https://news.airbnb.com/about-us/

• Read

  Airbnb, Inc. — Form 10-K for the year ended 31 December 2025 (533 million nights and seats booked in 2025 and 492 million in 2024; GBV $91.3 billion; ~50 currencies; ~20 local payment methods; payment held until check-in and payout generally on the business day after the scheduled check-in; $6.891 billion of cash held on behalf of customers; system of trust including risk scoring, reviews and anti-party technology), filed 12 February 2026: https://www.sec.gov/Archives/edgar/data/1559720/000155972026000004/abnb-20251231.htm

• Read

  Airbnb, Inc. — Form 10-K for the year ended 31 December 2024 (payout "generally occurs 24 hours after the scheduled check-in"): https://www.sec.gov/Archives/edgar/data/1559720/000155972025000010/abnb-20241231.htm

• Blog

  Airbnb Help Center — Sync your Airbnb calendar with other websites (imported calendars update automatically every 3 hours; Refresh; .ics links): https://www.airbnb.com/help/article/99

• Blog

  Airbnb Help Center — How Smart Pricing works ("hundreds of factors"; host minimum and maximum): https://www.airbnb.com/help/article/1168

Airbnb engineering and research:

• Paper

  Mustafa Abdool et al. — Applying Embedding-Based Retrieval to Airbnb Search (root and leaf services; retrieval, first-stage and setwise models; ~100,000 available homes in popular locations; ~10,000 listing updates a second; ±3 days = 49 combinations; precomputed availability and pricing; IVF over HNSW; Euclidean distance; +0.31% conversion, ~16% less compute), arXiv, January 2026: https://arxiv.org/abs/2601.06873

• Blog

  Airbnb Engineering — Embedding-Based Retrieval for Airbnb Search (two-tower model with the listing tower computed daily; trip-based negatives): https://airbnb.tech/ai-ml/embedding-based-retrieval-for-airbnb-search/

• Paper

  Malay Haldar et al. — Learning to Rank for Maps at Airbnb (18 pins; 95% of searchers click ≤ 12 pins; bookability filter +1.9% uncancelled bookings over 34 million searchers per arm; mini-pins get 8× fewer clicks), KDD 2024: https://arxiv.org/abs/2407.00091

• Blog

  Airbnb Engineering — Improving Search Ranking for Maps (re-centring the map: +0.27% uncancelled bookings, 1.5% fewer map moves): https://airbnb.tech/ai-ml/improving-search-ranking-for-maps/

• Paper

  Mihajlo Grbovic and Haibin Cheng — Real-time Personalization using Embeddings for Search Ranking at Airbnb (search ranking and similar listings drive 99% of conversions; one listing accepts one guest for a set of dates), KDD 2018: https://www.kdd.org/kdd2018/accepted-papers/view/real-time-personalization-using-embeddings-for-search-ranking-at-airbnb

• Blog

  Mihajlo Grbovic — Listing Embeddings in Search Ranking (32-dimensional embeddings for 4.5 million active listings from 800 million search click sessions), Airbnb Engineering, 2018: https://medium.com/airbnb-engineering/listing-embeddings-for-similar-listing-recommendations-and-real-time-personalization-in-search-601172f7603e

• Paper

  Malay Haldar et al. — Applying Deep Learning to Airbnb Search (from gradient-boosted trees to neural networks), KDD 2019: https://arxiv.org/abs/1810.09591

• Paper

  Peng Ye et al. — Customized Regression Model for Airbnb Dynamic Pricing (booking probability per listing-night, a price regression with a customised loss, personalization; powers Price Tips and Smart Pricing), KDD 2018: https://www.kdd.org/kdd2018/accepted-papers/view/customized-regression-model-for-airbnb-dynamic-pricing

• Blog

  Airbnb Engineering — Pay as a Local (payments subdomains: Pay-in, Payout, Processing, Ledger, Settlement and Reconciliation; 20+ local payment methods in 14 months; redirect, async and direct flows; webhooks): https://airbnb.tech/payments/pay-as-a-local/

• Blog

  Jon Chew — Avoiding Double Payments in a Distributed Payments System (Orpheus: pre-RPC, RPC and post-RPC phases; reads from the primary; retryable and non-retryable errors), Airbnb Engineering, 2019: https://medium.com/airbnb-engineering/avoiding-double-payments-in-a-distributed-payments-system-2981f6b070bb

Reporting:

• Blog

  InfoQ — Airbnb's Machine Learning Approach to Financial Fraud (targeted friction: micro-authorisations, 3-D Secure, billing-statement verification; Airbnb absorbs chargebacks; from David Press's Airbnb Engineering post), 20 March 2018: https://www.infoq.com/news/2018/03/financial-fraud-ml-airbnb/

• Read

  VentureBeat — Airbnb tweaks review system so guests don't fear retaliation from hosts (reviews hidden until both are submitted or 14 days pass), 2014: https://venturebeat.com/business/airbnb-tweaks-review-system-so-guests-dont-fear-retaliation-from-hosts/

Standards:

• Docs

  RFC 5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar): https://www.rfc-editor.org/rfc/rfc5545

Design note: the architecture, code, thresholds, polling schedules, dashboards and every number labelled as an assumption or estimate are an illustrative design for the problem, not a description of Airbnb's internal systems beyond what Airbnb has published. The search volume, average stay, iCal adoption and New Year's figures are assumptions.

Further Reading#

Related systems to study:

• Read

  Google Maps (Bonus Problem 22 in this series): geographic partitioning, tiles and live data that changes underneath queries

• Read

  Instagram (Bonus Problem 21): a retrieve-then-rank funnel for a personal feed

• Read

  Razorpay (Bonus Problem 18): payment gateways, settlement and reconciliation from the provider's side

• Read

  BookMyShow (Bonus Problem 16): seats that must never be sold twice, under a flash crowd

Papers and posts:

• Paper

  Malay Haldar et al. — Learning To Rank Diversely at Airbnb (ranking a page as a set), 2022: https://arxiv.org/abs/2210.07774

• Blog

  Airbnb Engineering — How Airbnb Achieved Metric Consistency at Scale (Minerva), 2021

Foundational concepts (this course):

• Read

  Week 1, Day 1 — Partitioning Deep-Dive

• Read

  Week 2, Day 2 — Idempotency in Practice

• Read

  Week 2, Day 5 — Distributed Cron and Job Scheduling

• Read

  Week 3, Day 5 — Audit Log System

• Read

  Week 5, Day 4 — Conflict Resolution

• Read

  Week 7, Day 1 — Search Fundamentals and Architecture

• Read

  Week 7, Day 3 — Query Processing and Relevance

• Read

  Week 8, Day 2 — Streaming vs Batch Processing

• Read

  Week 9, Day 5 — Security Architecture

"Search fast on a copy, decide exactly on the source, and account for every unit of money you hold for someone else."