Skip to content

How an Airbnb-like stays marketplace might evolve

Millions of unique homes, each with its own calendar, price rules and host. How availability-aware search, payments held in escrow, trust and safety, and internationalisation shape a two-sided marketplace.

The user problem and the hard parts

A guest wants a place that matches the photos, is free on their dates, at a total price they understand, from a host they can trust. A host wants bookings from guests who will respect their home, and to be paid reliably. Unlike a hotel, every listing is unique and every host is a small, independent business.

The hard engineering problems:

  • Search with availability calendars: "a 2-bedroom in Lisbon, 12–16 June, under €150/night" must filter millions of listings by geography, attributes and whether every one of those nights is free. Availability changes constantly.
  • Pricing: nightly prices vary by date, length-of-stay discounts, cleaning fees, taxes that depend on the city, currency conversion. The total shown in search must match checkout.
  • Payments and payouts: the guest pays at booking; the host is paid after check-in. The platform holds money in between, in many currencies, and must handle cancellations and refunds by policy.
  • Trust and safety: fake listings, account takeovers, fraudulent cards, party bookings, discrimination. Reviews only work if they are hard to fake.
  • i18n · internationalisation: dozens of languages, currencies, date formats, right-to-left scripts, and local laws (registration numbers, night caps in some cities).

How the architecture might evolve

An Airbnb-like stays marketplace

A plausible architecture for a peer-to-peer accommodation marketplace at each scale. Airbnb has publicly discussed moving from a Ruby on Rails monolith toward services; the details here are illustrative.

  1. 1
    Stage 1 · Early marketplace
    10k listings · 500 bookings/day
    Server-rendered web monolith (e.g. Rails or Django)MySQL/PostgreSQLPayment provider with delayed payoutsObject storage + CDN for photosEmail notifications

    One codebase lets a small team change search, booking and payments in one pull request. Photos are the product, so a for images comes early.

  2. 2
    Stage 2 · Growth
    500k listings · 20k bookings/day
    Search engine with geo queriesCalendar table (one row per listing per night)Redis caching of listing pagesBackground workers for payouts, emails, image processingFraud rules on signup and payment

    Geographic and attribute search leaves the relational database. Calendars become explicit night-by-night data so availability filtering is a set operation, not date-range arithmetic in application code.

  3. 3
    Stage 3 · Global marketplace
    5M listings · 200k bookings/day
    Services split out of the monolith: search, pricing, booking, payments, messaging, reviewsEvent bus for listing and calendar changesML ranking for search resultsTrust and safety platform (risk scoring, manual review queues)Translation and localisation pipeline

    Hundreds of engineers in one monolith slow each other down ( in action). Services follow team boundaries. Events keep the search index fresh when hosts edit calendars.

  4. 4
    Stage 4 · Platform
    Global · many product lines
    Payments platform with multi-currency ledgerUnified data platform and experimentationRegional compliance services (tax, registration)Service mesh with standardised observability

    Money in dozens of currencies with taxes and holds needs a proper double-entry ledger. Regulation becomes per-city logic that deserves its own owners.

Search with calendars, then book

A plausible architecture for Stage 3 might look like this. The key idea: search works on a denormalised copy of availability, booking works on the source of truth.

Click a component

Click any component to see what it does.

Engineering trade-offs

Availability as date ranges

  • Compact storage
  • Natural for hosts ("blocked 1–15 July")
  • Overlap queries are complex and slow at search time
  • Per-night prices don't fit
Choose when: Small catalogues with simple pricing.

One row per listing per night

  • Per-night price and status
  • Simple set logic for booking
  • Hundreds of rows per listing per year
  • Needs a compact derived form for search
Choose when: Dynamic per-night pricing and large search volume.

Keep the monolith

  • One deploy, easy refactors, no network calls between modules
  • Hundreds of engineers block each other
  • One bad deploy affects everything
Choose when: Teams are small enough to coordinate; consider a first.

Split into services

  • Teams deploy independently
  • Different scaling for search vs payments
  • Network failures, distributed tracing, data duplication
  • Cross-service changes need coordination
Choose when: Coordination cost inside the monolith clearly exceeds the distributed-systems tax.

Practical exercise

Search says €120, checkout says €138

Guests complain that the price in search results is lower than at checkout. You find that search computes totals from a nightly price cached in the search index, while checkout calls the pricing service with cleaning fee, local tourist tax and a currency rate fetched live. Design a fix that keeps search fast.