Airbnb / Booking#

Q: How does Airbnb prevent double booking?

The availability service treats date ranges as atomic units behind a transactional store. A booking acquires a short hold, then a charge confirms it; conflicting holds fail fast with a clear error.

Q: How does Airbnb search by location and dates?

Listings are indexed in a geo capable search engine like Elasticsearch with date availability bitmaps. Queries combine geo radius, date filters, price, amenities, and personalization scores.

Q: How does Airbnb power dynamic pricing for hosts?

A pricing service ingests demand signals, comparable listings, seasonality, and host preferences. It suggests nightly rates and exposes a price tip API the host can opt into for automatic updates.

Q: What does the booking flow look like in Airbnb?

Guests request a quote, place a hold on the calendar, run payment authorization, and only then commit the reservation. Failed payments release the hold so the dates become available again.

Q: How are guest and host reviews kept honest?

Both parties write reviews blind within a fixed window. Reviews are revealed only after both submit or the window closes, so neither can retaliate based on the other's words.

Problem statement (interviewer prompt)

Design Airbnb / Booking.com: hosts list properties with calendars, guests search by location + dates + filters, view availability, get a quote, hold dates, pay, and confirm. Strict no-double-booking; dynamic pricing; guest-host messaging.

flowchart LR
  G[Guest]
  H[Host]
  L[Listing Service]
  SRCH[Search]
  AVAIL[Availability]
  BOOK[Booking]
  PAY[Payment]
  G --> SRCH --> L
  G --> AVAIL
  G --> BOOK --> PAY
  H --> L
  H --> AVAIL

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class G,H,L,SRCH,AVAIL,BOOK,PAY service;

flowchart TB
  subgraph Apps
    GUEST[Guest]
    HOST[Host]
  end

  subgraph Edge
    CDN
    GW
  end

  subgraph Listing
    LSVC[Listing Service]
    LDB[(Listings)]
    IMG[Images / S3]
    DESC[Descriptions / translations]
  end

  subgraph Search[Search & Discovery]
    SRCH[Search API]
    IDX[(Search index<br/>geo + filters)]
    REC[Ranking + personalization]
    HMAP[Map tile aggregation]
  end

  subgraph Avail[Availability & Pricing]
    AV[Availability Service]
    AVDB[(Calendar per listing)]
    PRICE[Pricing engine<br/>dynamic + smart pricing]
    BLOCK[Manual blocks]
  end

  subgraph Book[Booking]
    QUOTE[Quote service<br/>price + fees + taxes]
    BSVC[Booking Service]
    BDB[(Bookings)]
    SAGA([Saga: hold-pay-confirm])
    PAYSVC[Payment]
    PG((Payment provider))
  end

  subgraph Comm
    MSG[Guest-host messaging]
    REV[Reviews]
  end

  subgraph Trust
    ID[ID verification]
    SAFE[Fraud & risk]
    DISP[Resolution / refund]
  end

  subgraph Notif
    EMAIL
    PUSH
    SMS
  end

  GUEST --> CDN --> GW
  HOST --> CDN
  GW --> Listing
  GW --> Search
  Search --> Avail
  GW --> Book
  Book --> Avail
  Book --> PAYSVC --> PG
  Book --> Comm
  Trust --- Book
  Notif --- Book

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class GUEST,HOST,LSVC,DESC,SRCH,REC,HMAP,AV,PRICE,BLOCK,QUOTE,BSVC,PAYSVC,MSG,REV,ID,SAFE,DISP service;
    class LDB,IDX,AVDB,BDB datastore;
    class SAGA compute;
    class IMG storage;
    class PG external;

Availability correctness#

Per-listing calendar: (date, state) with states available / blocked / pending / booked.
Booking flow holds date range with TTL, charges card, then confirms.
Optimistic CAS on date range: detect conflict at commit.

Search relevance#

Personalized ranker combining price, quality, location, host responsiveness, time-to-respond.
Geo + filter index keyed by S2 cell + amenities posting lists.

Pricing#

Dynamic / smart pricing per night based on demand, lead time, weekday, events.

Glossary & fundamentals#

Concepts referenced in this design. Each row links to its canonical page; the tag column shows whether it is a high-level (HLD) or low-level (LLD) concept.

Tag	Concept	What it is	Page
`HLD`	CDN	edge caching for static assets	cdn
`HLD`	Distributed transactions	2PC, TCC, sagas, outbox/inbox	distributed-transactions
`HLD`	Geo indexing	Geohash, Quadtree, S2, H3, R-tree	geo-indexing
`LLD`	Concurrency primitives	mutex, semaphore, RW lock, atomic, CAS	concurrency-primitives

Quick reference#

Functional#

Search by location, date, filters.
View listing detail, availability calendar.
Quote → reserve → pay → confirm.
Host calendar, smart pricing.
Messaging, reviews, support.

Non-functional#

Strong consistency: no double-booking.
p99 search < 500 ms; quote < 300 ms.
99.99% availability.

Capacity#

Listings: 7M+ active (Airbnb), Booking 28M+.
Searches: many millions/day, bursty at peak travel.

Schema#

listings(id, host_id, geo, amenities, price)
calendar(listing_id, date, state, version)
bookings(id, listing_id, guest_id, dates[], total, status, idempotency_key)
reviews(id, listing_id, ratings[], text)

Trade-offs#

Date-range locking: lock the whole window, not single date - careful with concurrency.
Search vs canonical stores: ES index for search, SQL for truth; sync via CDC.
Pricing rules are a complex DSL; isolate as a service.

Refs#

Airbnb engineering blog (search ranking, RECs, MySQL sharding via Vitess).
Booking.com engineering posts on A/B & search.
ByteByteGo "Design Airbnb".

FAQ#

How does Airbnb prevent double booking?#

The availability service treats date ranges as atomic units behind a transactional store. A booking acquires a short hold, then a charge confirms it; conflicting holds fail fast with a clear error.

How does Airbnb search by location and dates?#

Listings are indexed in a geo capable search engine like Elasticsearch with date availability bitmaps. Queries combine geo radius, date filters, price, amenities, and personalization scores.

How does Airbnb power dynamic pricing for hosts?#

A pricing service ingests demand signals, comparable listings, seasonality, and host preferences. It suggests nightly rates and exposes a price tip API the host can opt into for automatic updates.

What does the booking flow look like in Airbnb?#

Guests request a quote, place a hold on the calendar, run payment authorization, and only then commit the reservation. Failed payments release the hold so the dates become available again.

How are guest and host reviews kept honest?#

Both parties write reviews blind within a fixed window. Reviews are revealed only after both submit or the window closes, so neither can retaliate based on the other's words.

Video walkthrough

Airbnb Data Warehouse Schema: Data Engineering Mock Interview : via Exponent