Airbnb

Overview

Airbnb connects guests looking for short-term stays with hosts offering their spaces. Behind a deceptively simple search box sits a two-sided marketplace that must solve four hard problems at once: geospatial and filtered search over millions of listings, concurrent availability to prevent double-booking, split payments with escrow-style holds, and a trust system built on two-way reviews.

Each side of the marketplace — supply (hosts and listings) and demand (guests) — has different scaling pressures, and the system’s hardest edges are where they meet: the booking transaction. A search can be eventually consistent and cached aggressively, but a booking must be strictly consistent, because selling the same night twice is the one mistake a marketplace cannot tolerate.

Scale

Requirements

High-Level Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

Search & Discovery

Search is the marketplace’s front door, and it is read-heavy: millions of guests browse for every one that books.

The 0->1 default: A single PostgreSQL table with lat/lng columns, filtered by a bounding box and guest count, is enough to launch. It is simple, transactional, and good enough for a few thousand listings.

The breakpoint: Once the listing catalog grows past tens of thousands and filters get richer (amenities, price ranges, instant-book), the database scan-and-filter pattern becomes too slow. The system evolves to a dedicated inverted search index that denormalizes each listing into a searchable document with geospatial fields and facets.

Loading diagram...

Cost drivers:

• Index freshness lag: a new listing may take seconds to minutes to appear, which is acceptable for search but not for booking.
• Egress and compute from re-ranking millions of candidates per query.
• Cache invalidation when a host edits a listing or a night gets booked.

Booking & Availability Concurrency

This is the system’s strict-consistency core. Two guests requesting the same listing for overlapping dates must never both succeed.

The 0->1 default: A calendar_day row per listing per night with a status column. Booking a stay runs inside a transaction that locks the relevant rows and flips them from available to reserved. Row-level locking is correct and simple.

The breakpoint: Lock contention appears when popular listings or high-traffic dates (holidays, events) attract many simultaneous requests. Contention turns into latency and deadlocks. The system evolves to optimistic concurrency: read the calendar versions, attempt a conditional update, and retry on conflict. For high-demand listings, a short-lived reservation hold in Redis reserves the nights for a few minutes while payment completes, so the database lock is held only briefly.

Loading diagram...

Why this matters: The hold decouples the slow, failure-prone payment step from the fast availability check. The database only commits the final state change, and the conditional WHERE clause makes double-booking impossible without holding a long lock.

Payments & Split Payouts

Payments in a marketplace are harder than in a normal store because money flows to a third party (the host), and the platform takes a cut.

The flow:

1. Guest is charged the full amount at booking confirmation.
2. Funds are held in escrow — the host is not paid yet.
3. After check-in (or a defined window), the host payout is scheduled.
4. The platform fee and taxes are split off; the remainder is sent to the host’s payout method.

Idempotency is non-negotiable. Every charge carries an idempotency key (often derived from the booking ID and attempt number). A retry from a dropped connection or a webhook redelivery must return the original result, not create a second charge. This is the same pattern that makes retries safe across the reliability lessons.

Cost drivers & breakpoints:

• Payment processor fees per transaction — significant at marketplace scale.
• Payout failures and retries requiring reconciliation jobs.
• Multi-currency conversion and region-specific tax rules, which push the payment service toward a rules engine rather than hardcoded logic.

Reviews & Trust

Trust is the marketplace’s moat, and reviews are its currency. Airbnb uses two-way reviews with delayed reveal:

• After a stay, both the guest and the host can leave a review.
• Neither review is published until both have submitted, or a 14-day window closes.
• This prevents the second reviewer from retaliating based on what the first wrote.

Consistency model: Reviews are eventually consistent. They are written to the primary database, published by a scheduled job when the reveal condition is met, and propagated to listing pages and search ranking signals. A review being briefly delayed is acceptable; a booking being double-sold is not. This split — strict consistency for transactions, eventual consistency for everything else — is the central architectural decision of the whole system.

Architectural Tradeoffs

# Learn From a Airbnb-like System

You are an expert software architect and teacher. I want to learn from a Airbnb-inspired system design (A two-sided marketplace for search, booking, payments, and trust) without pretending this is the exact private production architecture.

Use the following reference as a learning model. Keep assumptions visible, avoid unsupported scale claims, and explain the engineering forces behind each design choice.

---

## System Design Reference
import { Mermaid, Scale, ComponentList, ComponentCard, Requirements, Tradeoff } from '@/components/mdx';

## Overview

Airbnb connects guests looking for short-term stays with hosts offering their spaces. Behind a deceptively simple search box sits a two-sided marketplace that must solve four hard problems at once: geospatial and filtered search over millions of listings, concurrent availability to prevent double-booking, split payments with escrow-style holds, and a trust system built on two-way reviews.

Each side of the marketplace — supply (hosts and listings) and demand (guests) — has different scaling pressures, and the system's hardest edges are where they meet: the booking transaction. A search can be eventually consistent and cached aggressively, but a booking must be strictly consistent, because selling the same night twice is the one mistake a marketplace cannot tolerate.

## Scale

<Scale items={{
  "Active listings": "7M+",
  "Bookings per night": "~1M+",
  "Countries served": "220+",
  "Guest arrivals (cumulative)": "1.5B+",
}} />

## Requirements

<Requirements
  functional={[
    'Search listings by location, dates, guest count, and filters',
    'Real-time availability calendar with no double-booking',
    'Booking lifecycle: request, confirm, pay, check-in, check-out',
    'Split payments: platform fee, host payout, taxes',
    'Two-way reviews with delayed reveal',
    'Guest-host messaging before and during a stay',
    'Dynamic pricing suggestions for hosts',
  ]}
  nonFunctio...

[Full prompt copied to clipboard]