Design a Booking & Reservation System
like Airbnb

"Design Airbnb" sits in every FAANG loop for a reason: it compresses three distinct hard problems into a single question. You need a workable answer to all three, not a deep dive into just one.

Start here before touching architecture. The NFR targets below drive every significant design decision in the article.

Functional requirements

Non-functional requirements

NFR reasoning

Airbnb's load profile is unusual: search traffic is enormous and spiky (every travel-season booking surge), but actual booking write volume is modest. The read:write ratio is extreme — roughly 500:1. This has a direct architectural implication: the system should be almost entirely read-optimised.

The architecture splits into two clearly separated planes: the search plane (read-heavy, latency-critical, eventual consistency acceptable) and the booking plane (write-important, correctness-critical, synchronous). A change-data-capture stream connects them.

Component breakdown

API Gateway / Load Balancer is the single entry point for all client traffic. It handles TLS termination, authentication token validation, and routes requests to the appropriate downstream service. Because search and booking have very different latency characteristics, routing them to separate service fleets allows independent scaling.

Search API translates guest queries (bounding box, date range, guest count, filters) into Elasticsearch queries. It checks the Redis results cache first on high-traffic queries (popular destination + date combinations) before hitting Elasticsearch. Results come back as listing IDs with scores; the service then enriches them with real-time pricing from a pricing service.

Booking API is the correctness-critical core. It handles the reserve → lock → write sequence, enforces the double-booking constraint, triggers notifications, and communicates with a payment service (out of scope here). It talks only to the Booking database — never to the search index.

Listing Service manages host-facing CRUD operations: creating listings, setting availability calendars, updating photos and descriptions. Changes propagate to both the Listing DB and, via CDC, to Elasticsearch.

Elasticsearch (search index) holds a document per listing: geo-point, available date ranges (encoded as a bitset or range list), price, amenity flags. Both the Search API and the Indexer consumer interact with it. The index is not the source of truth — it's a read-optimised projection of the Listing and Booking databases.

Redis (search results cache) caches rendered search result pages for popular origin+date combinations (e.g., "Paris, 3–5 guests, July 4–10"). Cache keys include all filter parameters; TTL is short (~30 s) to bound staleness.

Booking DB (PostgreSQL, sharded by listing_id) is the source of truth for all reservations. It holds the booking records and the availability calendar table. The unique constraint on (listing_id, date) lives here. Sharding by listing_id co-locates all bookings for a listing on the same shard, making availability queries and locking efficient.

Listing DB (PostgreSQL) holds listing metadata: title, description, amenities, photos, host details, pricing tiers. Reads are served from read replicas; writes go to the primary.

Kafka event pipeline is implemented using the outbox pattern: the Booking API writes a row to an outbox table inside the same PostgreSQL transaction as the booking record. A Debezium connector reads from the outbox table via WAL and publishes typed semantic events (booking.confirmed, booking.expired, listing.updated) to Kafka. This is important: a raw Debezium CDC tap on the main tables produces low-level row-mutation events — not domain events. The outbox pattern bridges the gap, ensuring typed application events are delivered reliably without coupling the booking transaction to Kafka availability. The Indexer consumer subscribes and drives Elasticsearch updates. Other consumers (notification service, analytics) can subscribe independently without coupling to the booking write path.

Indexer is a stateless consumer that reads from Kafka and writes to Elasticsearch. It handles partial failures gracefully: if it crashes, it replays from its last committed Kafka offset. This is why Kafka's durable log is essential — it decouples the indexer's liveness from the booking transaction.

Notification Service is a separate Kafka consumer on the same booking event stream. On a booking.confirmed event it fans out a push notification to the host (mobile push via FCM/APNs, with email fallback). On a booking.expired event it notifies the guest. Delivery is at-least-once: if the consumer crashes after processing but before ACKing the Kafka offset, it re-processes the event on restart — notifications suppress duplicates using a notification_id keyed on (booking_id, event_type) stored in Redis with a 7-day TTL (matching Kafka's default retention; a 24 h TTL would allow duplicates if a consumer replays events older than one day).

Architectural rationale

Real-world comparison

Before designing the booking flow, you have to answer a deceptively simple question: how do you represent whether a listing is available on a given date? The answer shapes the conflict detection, the search index document structure, and the calendar update logic.

The encoding choice is constrained by two conflicting requirements established in §2 and §4: the booking DB needs atomic row-level locking (rules out bitset compare-and-swap for multi-day ranges), and the search index needs O(1) bitwise date-range evaluation (rules out scanning one relational row per listing per day at 150 M listing scale). No single encoding satisfies both, which is why the final design uses two different representations in two different systems.

There are three main approaches. All eventually appear in the discussion — but they're not equivalent, and the right choice depends on which operation needs to be fastest.

Our choice for this system: Use row-per-day (①) in the booking database and bitset (③) in the Elasticsearch search index. They serve different purposes. The relational row-per-day model gives us the unique constraint enforcement and simple atomic UPDATE that make double-booking structurally impossible. The bitset in Elasticsearch lets the search index quickly evaluate "are all nights of this 7-night trip available?" with a bitwise AND, without scanning multiple rows per listing per query.

-- Booking DB schema (one row per listing-day)
CREATE TABLE calendar_availability (
  listing_id  BIGINT      NOT NULL,
  stay_date   DATE        NOT NULL,
  available   BOOLEAN     NOT NULL DEFAULT TRUE,
  booking_id  BIGINT,
  PRIMARY KEY (listing_id, stay_date)   -- unique constraint
);

-- Prerequisite: calendar_availability is pre-seeded with one row per date
-- per listing when the host activates the listing (available = TRUE for each date).

-- Atomic availability claim (all-or-nothing for the date range)
BEGIN;
  -- Step 1: Lock AVAILABLE rows for the date range
  SELECT count(*) FROM calendar_availability
  WHERE listing_id = $1
    AND stay_date BETWEEN $2 AND $3
    AND available = TRUE
  FOR UPDATE;
  -- If count < requested nights → one or more dates unavailable; ROLLBACK + 409

  -- Step 2: Mark dates as booked
  UPDATE calendar_availability
  SET available = FALSE, booking_id = $booking_id
  WHERE listing_id = $1
    AND stay_date BETWEEN $2 AND $3;

  -- Step 3: Insert booking record (with outbox entry for Kafka)
  INSERT INTO bookings (...) VALUES (...);
  INSERT INTO outbox (event_type, payload) VALUES ('booking.confirmed', ...);
COMMIT;

The two most critical endpoints are search and booking creation. Both are guest-facing and sit on the hot path.

POST /search/listings

Use POST (not GET) for search because the request body can be large (complex filters, bounding box polygons) and GET requests with long query strings are unwieldy and don't benefit from request caching. Note: the response can still be cached aggressively by the application layer using the request body as a cache key: the Redis search cache in §8 uses a SHA-256 hash of the full request body as the cache key, which is why CDN non-cacheability of POST is not a problem here.

// Request
{
  "geo": {
    "type": "bounding_box",
    "top_left": { "lat": 48.92, "lon": 2.25 },
    "bottom_right": { "lat": 48.81, "lon": 2.42 }
  },
  "check_in": "2024-07-04",
  "check_out": "2024-07-11",
  "guests": 3,
  "filters": {
    "max_price_per_night": 250,
    "amenities": ["wifi", "kitchen"],
    "property_type": ["entire_place"]
  },
  "page_token": "eyJ..."  // cursor-based pagination
}

// Response 200 OK
{
  "results": [
    {
      "listing_id": "L-8823771",
      "title": "Cosy studio near the Marais",
      "price_per_night": 189,
      "total_price": 1323,
      "rating": 4.87,
      "review_count": 142,
      "location": { "lat": 48.858, "lon": 2.361 },
      "thumbnail_url": "https://cdn.example.com/...",
      "availability_snapshot_age_s": 34  // freshness signal
    }
  ],
  "next_page_token": "eyJ...",
  "total_count": 847
}

POST /bookings

Idempotency key is mandatory — mobile clients retry on network failures, and a missing idempotency key would create duplicate bookings. The key should be client-generated (UUID) and stored server-side with a 24-hour TTL. Repeated calls with the same key return the original response.

// Request — Idempotency-Key header required
// POST /bookings
// Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000
{
  "listing_id": "L-8823771",
  "check_in": "2024-07-04",
  "check_out": "2024-07-11",
  "guests": 3,
  "guest_message": "Looking forward to our trip!",
  "price_quote_id": "PQ-991234"  // locks in the price shown at search time
}

// Response 201 Created (instant-book) / 202 Accepted (request-to-book)
{
  "booking_id": "BK-44123890",
  "status": "confirmed",  // or "pending_host_approval"
  "listing_id": "L-8823771",
  "check_in": "2024-07-04",
  "check_out": "2024-07-11",
  "total_price": 1323,
  "confirmation_code": "HMAB4C"
}

// Conflict: 409 Conflict
{
  "error": "dates_unavailable",
  "message": "One or more requested dates are no longer available.",
  "conflicting_dates": ["2024-07-06", "2024-07-07"]
}

Optional endpoints by level

The system has two distinct critical paths. The search path must be fast (the <300 ms NFR from §2 means caching is mandatory, not optional). The booking path must be correct (the double-booking-prevention NFR from §2 means the distributed lock and DB transaction are mandatory, not optional).

Tradeoff: distributed lock duration vs. booking latency

The lock TTL of 200 ms is tight by design. If the lock is held longer (e.g., 2 s), competing requests are blocked for 2 s — visible as high booking latency. If the lock TTL is too short, the lock may expire before the DB transaction commits — but the DB's SELECT FOR UPDATE still serialises the second writer: it blocks until the first transaction commits or rolls back, and the unique constraint on (listing_id, stay_date) catches any race that slips through. The Redis lock is defence-in-depth, not the primary guard; the DB is the last line of defence.

The data model is shaped by access patterns — not by what's convenient to normalise. Access patterns come first.

Access patterns

Two things stand out. First, the availability check is the hottest write-path query and needs to be both fast (range scan) and atomic (must combine check + claim in one transaction). This drives the row-per-day calendar model. Second, search never touches these tables directly — it reads from Elasticsearch. Those two planes must stay separate.

The caching hierarchy is not one-size-fits-all. Search results have different staleness budgets and access patterns than listing detail pages or availability calendars. Each cache layer exists for a specific reason, anchored to the architecture in §4.

Cache layer breakdown

At peak scale (holidays, summer surge), traffic multiplies 3–5× across all planes simultaneously. The architecture must handle this without reconfiguration.

Security & compliance

Classic probes