TLDR: Design a hotel booking system like Airbnb. This article covers availability tracking with date-level inventory, double-booking prevention via optimistic locking, two-phase reservation (hold → confirm), geospatial search with Elasticsearch, and payment pre-authorisation — with concrete SQL schema, Redis key layout, and a targeted Java @Version snippet.

TLDR: Booking systems must solve one problem above all others: preventing two guests from successfully reserving the same room for the same night, even under high concurrency.

At 11:59 PM on New Year's Eve, two guests click "Book Now" on the same Manhattan apartment. Both see "Available." Both reach the payment screen. Both receive a confirmation email. Their hosts wake up to two strangers at the door on the same night. This is the double-booking race condition, and it is the reason hotel booking systems are a favourite system design interview question.

Airbnb's engineering team encountered this exact failure mode as the platform scaled beyond 100 million nights booked. The fix required rethinking availability tracking at the database row level, introducing a two-phase hold-then-confirm reservation model, and separating the read-heavy search workload from the write-critical booking path.

By the end of this walkthrough you will know why availability tracking uses a date-level inventory table rather than a simple "is booked" flag, why optimistic locking outperforms pessimistic locks for most booking loads, and why search and booking must never share the same data store.

📖 The Double-Booking Problem: Two Guests, One Room, One Disaster

Actors

Use Cases

• Primary interview prompt: Design a hotel or room booking platform like Airbnb or Booking.com.
• Core user journeys:
  • Search — guest queries rooms by city or coordinates, date range, guest count, and filters (price, amenities, rating)
  • View availability — guest views the per-night calendar for a specific listing before committing
  • Create booking — guest selects dates → system places a 15-minute hold → payment pre-auth → confirmed booking
  • Cancel booking — guest cancels; system releases held or booked slots and triggers a refund per the host's cancellation policy
  • Host availability management — host blocks or opens dates; sets nightly price and minimum stay rules
  • Payment lifecycle — pre-authorise at booking creation; capture 48 h before check-in; refund on cancellation
  • Reviews — post-checkout; guest and host each submit a rating
• Read and write paths are explained separately to keep bottlenecks and consistency boundaries explicit.

The double-booking race condition is the reason this system appears in nearly every senior engineering interview: it looks like straightforward CRUD until you model two users simultaneously selecting the same room.

🔍 Functional Requirements: What the System Must Cover

In Scope

• Room search — GET /search with geo bounding box or geo_distance, date range, guest count, price ceiling
• Availability calendar — GET /rooms/{id}/availability?from=&to= returning per-date status
• Create booking — POST /bookings with Idempotency-Key; places hold then awaits payment confirmation
• Cancel booking — DELETE /bookings/{id}; configurable refund policy per host (flexible, moderate, strict)
• Payment pre-auth and capture — integrate via Payment Service; pre-auth at hold; capture before check-in
• Host calendar management — block dates, set nightly pricing, manage minimum stay and advance notice rules

Out of Scope (v1 boundary)

• Dynamic pricing and revenue optimisation (ML-driven surge pricing algorithms)
• Fraud scoring and risk model evaluation during booking
• Multi-currency FX conversion
• Loyalty programmes and reward redemption

Functional Breakdown

A strong answer names non-goals explicitly. Interviewers use this to judge prioritisation quality and architectural maturity under time constraints.

⚙️ Non-Functional Requirements and Design Goals

🧠 Deep Dive: Estimations and Design Goals

The Internals: Data Model and Locking Strategy

Three tables form the availability backbone. The central insight is that availability is tracked at the date-slot level — each individual night is an independent lockable unit. This design means holding December 31st does not require locking December 30th, which maximises write concurrency for partial-week bookings.

CREATE TABLE rooms (
    room_id         UUID        PRIMARY KEY DEFAULT gen_random_uuid(),
    host_id         UUID        NOT NULL,
    title           TEXT        NOT NULL,
    latitude        DECIMAL(9,6) NOT NULL,
    longitude       DECIMAL(9,6) NOT NULL,
    price_per_night INT         NOT NULL,  -- stored in cents; never FLOAT
    max_guests      SMALLINT    NOT NULL,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_rooms_host ON rooms(host_id);

-- One row per room per night — the lockable unit of availability.
-- The `version` column is the optimistic locking counter.
CREATE TABLE availability_slots (
    slot_id     UUID        PRIMARY KEY DEFAULT gen_random_uuid(),
    room_id     UUID        NOT NULL REFERENCES rooms(room_id),
    slot_date   DATE        NOT NULL,
    status      TEXT        NOT NULL DEFAULT 'available'
                CHECK (status IN ('available', 'held', 'booked', 'blocked')),
    booking_id  UUID,                 -- NULL when available or blocked
    version     INT         NOT NULL DEFAULT 0,  -- incremented on every UPDATE
    held_until  TIMESTAMPTZ,          -- expiry for held slots; 15-minute TTL
    UNIQUE (room_id, slot_date)       -- one slot per room per night; DB backstop
);
CREATE INDEX idx_slots_room_date   ON availability_slots(room_id, slot_date);
CREATE INDEX idx_slots_held_expiry ON availability_slots(status, held_until)
    WHERE status = 'held';  -- efficient sweep for expired holds

-- Each booking spans one or more availability_slots rows.
CREATE TABLE bookings (
    booking_id      UUID        PRIMARY KEY DEFAULT gen_random_uuid(),
    idempotency_key TEXT        UNIQUE NOT NULL,  -- client-supplied dedup anchor
    room_id         UUID        NOT NULL REFERENCES rooms(room_id),
    guest_id        UUID        NOT NULL,
    check_in        DATE        NOT NULL,
    check_out       DATE        NOT NULL,
    status          TEXT        NOT NULL DEFAULT 'pending'
        CHECK (status IN ('pending','held','confirmed','cancelled','expired')),
    total_cents     BIGINT      NOT NULL,
    payment_auth_id TEXT,               -- pre-auth reference from Payment Service
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    confirmed_at    TIMESTAMPTZ,
    cancelled_at    TIMESTAMPTZ
);
CREATE INDEX idx_bookings_room_dates ON bookings(room_id, check_in, check_out);
CREATE INDEX idx_bookings_guest      ON bookings(guest_id, created_at DESC);

The version column is the double-booking prevention mechanism. Every UPDATE on a slot increments version by 1. A concurrent UPDATE that reads the old version returns 0 rows — the application layer treats 0 rows as a conflict and retries or rejects the booking attempt. The UNIQUE(room_id, slot_date) constraint is the database-level backstop that catches any conflict the application layer misses.

📊 Data Model: Key Relationships

erDiagram
    ROOMS {
        uuid room_id PK
        uuid host_id
        text title
        decimal latitude
        decimal longitude
        int price_per_night
        smallint max_guests
    }
    AVAILABILITY_SLOTS {
        uuid slot_id PK
        uuid room_id FK
        date slot_date
        text status
        uuid booking_id FK
        int version
        timestamptz held_until
    }
    BOOKINGS {
        uuid booking_id PK
        text idempotency_key UK
        uuid room_id FK
        uuid guest_id
        date check_in
        date check_out
        text status
        bigint total_cents
        text payment_auth_id
    }
    ROOMS ||--|{ AVAILABILITY_SLOTS : "one slot per night"
    BOOKINGS ||--|{ AVAILABILITY_SLOTS : "holds or books"

Redis key layout:

Estimations

Assumptions for Airbnb-scale:

Key insight: The search-to-booking QPS ratio is roughly 20:1. This asymmetry drives the single most important architectural decision: Elasticsearch for search (optimised for geo and date read throughput) and PostgreSQL for bookings (optimised for ACID writes with row-level versioning). Mixing both workloads in one database would cause read-write contention during the booking peaks that matter most.

Design Goals

Performance Analysis: Bottlenecks and Scaling Pressure

📊 High-Level Architecture

Five services handle the booking platform. The critical topology decision is that the Search Service and the Booking Service never share a database: Elasticsearch absorbs all geo and date read traffic; PostgreSQL handles only ACID availability writes. Kafka decouples booking confirmation events from notification delivery and Elasticsearch index updates.

graph TD
    Client["🧑 Guest / Host Client"]
    GW["API Gateway\n(Auth · Rate Limit · Routing)"]
    Search["Search Service\n(Elasticsearch)"]
    Avail["Availability Service\n(PostgreSQL)"]
    Booking["Booking Service\n(PostgreSQL)"]
    Payment["Payment Service\n(Stripe / Adyen)"]
    Notify["Notification Service\n(SES / FCM)"]
    Redis["Redis\n(Availability Cache\nIdempotency Store\nBooking Locks)"]
    ES["Elasticsearch\n(Geo + Date Index)"]
    DB[("PostgreSQL\nBookings + Availability")]
    Kafka["Kafka\n(Event Bus)"]

    Client --> GW
    GW --> Search
    GW --> Booking
    Search --> ES
    Search --> Redis
    Booking --> Avail
    Booking --> Redis
    Avail --> DB
    Booking --> DB
    Booking --> Payment
    Booking --> Kafka
    Kafka --> Notify
    Kafka --> ES

The API Gateway enforces authentication and rate limiting (guests are limited to 10 booking attempts per minute to prevent inventory squatting). It routes search traffic to the Search Service and booking traffic to the Booking Service, keeping the two latency profiles and consistency requirements fully isolated.

Component responsibilities at a glance:

🌍 Real-World Application: How Airbnb Engineers Eliminated Double-Bookings

Airbnb's early architecture used a naive check-and-book pattern: read availability, then if available create the booking. This is a classic TOCTOU (time-of-check-time-of-use) race condition. Two guests reading at the same millisecond both see the room as available, both write a booking row, and both receive a confirmation email — while the host faces an impossible situation.

The production fix was a two-phase model with optimistic locking on the availability slot row:

Phase 1 — HOLD: The Booking Service attempts to UPDATE all availability_slots rows for the requested dates from available to held, checking the current version value. If any slot's UPDATE returns 0 rows affected (because another request already incremented that version), the hold fails immediately. The guest sees "Room no longer available for selected dates."

Phase 2 — CONFIRM: After successful payment pre-authorisation, the service transitions slot status from held to booked, again with a version check. On cancellation or payment failure, it reverts to available.

// JPA @Version causes Hibernate to include the version in every UPDATE WHERE clause.
// If the version has changed (another request won the race), Hibernate throws
// OptimisticLockingFailureException — the application layer retries up to 3 times.
@Entity
@Table(name = "availability_slots")
public class AvailabilitySlot {

    @Id
    private UUID slotId;

    @Column(nullable = false)
    private UUID roomId;

    @Column(nullable = false)
    private LocalDate slotDate;

    @Enumerated(EnumType.STRING)
    private SlotStatus status;   // AVAILABLE → HELD → BOOKED / back to AVAILABLE

    @Version                     // Hibernate increments this on every UPDATE
    private int version;         // Concurrent UPDATE with stale version → exception

    private Instant heldUntil;   // non-null only when status = HELD
}

// Booking Service: retry up to 3 times with exponential backoff on OCC conflict.
@Retryable(value = OptimisticLockingFailureException.class,
           maxAttempts = 3, backoff = @Backoff(delay = 100, multiplier = 2))
public BookingResult holdDates(UUID roomId, LocalDate checkIn,
                               LocalDate checkOut, UUID bookingId) {
    List<AvailabilitySlot> slots =
        slotRepository.findByRoomIdAndDateRange(roomId, checkIn, checkOut);
    slots.forEach(slot -> {
        if (slot.getStatus() != SlotStatus.AVAILABLE)
            throw new RoomNotAvailableException(slot.getSlotDate());
        slot.setStatus(SlotStatus.HELD);
        slot.setHeldUntil(Instant.now().plus(Duration.ofMinutes(15)));
    });
    return new BookingResult(slotRepository.saveAll(slots));  // version incremented here
}

For the most contested listings — a city-centre apartment listed during a sold-out concert weekend — optimistic locking alone can generate a thundering herd of retries. A Redis SETNX front-door lock on the (roomId, dateRange) key serialises concurrent HOLD attempts before they reach the database, eliminating unnecessary OCC conflicts:

// SETNX (SET if Not eXists) acquires a lock that expires automatically.
// If the lock is already held, the request is rejected immediately rather than
// hammering the DB with 200 concurrent optimistic-lock retries.
String lockKey = String.format("booking:lock:%s:%s:%s",
    roomId, checkIn, checkOut);
Boolean acquired = redisTemplate.opsForValue()
    .setIfAbsent(lockKey, "1", Duration.ofSeconds(20));
if (Boolean.FALSE.equals(acquired)) {
    throw new BookingLockConflictException(
        "Room is being reserved. Please retry in a moment.");
}
// Proceed to the database HOLD inside a try/finally that releases the lock.

This two-layer pattern — Redis front-door lock for hot listings, OCC for the long tail — is the industry-standard approach that allows a platform like Airbnb to absorb sudden booking spikes on popular properties without database deadlocks or runaway retry storms.

⚖️ Trade-offs & Failure Modes in Booking Concurrency and Availability

Failure modes to discuss in an interview:

• Hold never confirmed (guest abandons checkout): Guest initiates a hold, then closes the browser. The slot stays held and blocks other guests until held_until expires. Mitigation: a background cron job running every 5 minutes selects all availability_slots WHERE status = 'held' AND held_until < NOW() and bulk-updates them back to available. The partial index idx_slots_held_expiry makes this sweep fast even at 2.5 billion rows.
• Payment succeeds but CONFIRM update fails: Guest is charged but booking status stays held. The guest has a pre-auth on their card and no confirmed booking. Mitigation: transactional outbox pattern — write a booking_events row in the same transaction as the payment response; a background reconciliation job re-drives the CONFIRM step using the stored event if the booking is still held after payment succeeds.
• Availability cache serves stale data during a booking wave: A room just held still shows "available" for up to 30 seconds for guests whose availability query was cached before the hold. Mitigation: publish a slot.status_changed Kafka event on every hold, confirm, and release; the cache consumer invalidates the Redis key immediately on receipt.
• Elasticsearch out of sync with PostgreSQL: A host marks dates as blocked in PostgreSQL, but the ES document still shows those dates as available for up to 5 seconds. Mitigation: the Availability Service performs an authoritative availability re-check from PostgreSQL at the start of every HOLD attempt — ES results are used only for display and filtering, never as the source of truth for the booking write.

🧭 Decision Guide: Concurrency Control Strategy for Room Booking

🧪 Practical Examples: Write Path and Read Path Walkthrough

Example 1: Guest Makes a Booking — The Concurrency-Safe Write Path

The following sequence shows the full booking flow from "Book Now" to confirmation email, with concurrency control at every critical step.

sequenceDiagram
    participant G as Guest
    participant BK as Booking Service
    participant RD as Redis
    participant AV as Availability Service
    participant PY as Payment Service
    participant KF as Kafka

    G->>BK: POST /bookings (Idempotency-Key: xyz, roomId, check-in/out)
    BK->>RD: GET idempotency:booking:xyz
    RD-->>BK: Cache miss — proceed
    BK->>RD: SETNX booking:lock:{roomId}:{dates} (TTL 20 s)
    RD-->>BK: Lock acquired
    BK->>AV: HOLD slots (version check; held_until = now + 15 min)
    AV-->>BK: Hold confirmed — all slot versions incremented
    BK->>PY: Pre-authorise payment (amountCents, paymentMethodId)
    PY-->>BK: Auth code returned
    BK->>AV: CONFIRM slots (status: held → booked, version check)
    AV-->>BK: Booking confirmed
    BK->>RD: SET idempotency:booking:xyz = response (TTL 24 h)
    BK->>KF: Emit booking.confirmed event
    KF-->>G: Confirmation email (via Notification Service, async)
    BK-->>G: HTTP 201 { bookingId, status: "confirmed" }

If the HOLD step returns an OCC conflict, the Booking Service retries up to 3 times with exponential backoff (100 ms, 200 ms, 400 ms). If all retries fail — indicating the room is genuinely being booked by another guest — it returns HTTP 409 "room no longer available for selected dates".

If the Redis lock is already held on the first attempt, the service returns HTTP 409 immediately. This prevents the thundering herd from even reaching the database during a booking wave on a hot listing.

Example 2: Guest Searches for Available Rooms — The Read Path

The read path deliberately avoids the booking database entirely. Elasticsearch handles geo and date filtering; Redis serves cached availability windows; only on a cache miss does the system touch PostgreSQL.

graph TD
    A["Guest: GET /search?lat=40.7&lon=-74.0\n&from=2025-12-31&to=2026-01-02&guests=2"]
    B["Search Service: hash query params → check Redis search cache"]
    C{Search cache hit?}
    D["Return cached search results\n(5-minute TTL)"]
    E["Elasticsearch: geo_distance + date range + price filter"]
    F["Availability Service: verify open slots for top results"]
    G{Availability cache hit?}
    H["Return from Redis availability cache\n(30-second TTL)"]
    I["PostgreSQL: query availability_slots\nfor matched room IDs and dates"]
    J["Merge ES results with confirmed availability\nCache result in Redis (30 s TTL)"]
    K["Return ranked results to guest\n(sorted by distance + rating)"]

    A --> B
    B --> C
    C -- Yes --> D
    C -- No --> E
    E --> F
    F --> G
    G -- Yes --> H
    G -- No --> I
    I --> J
    H --> K
    J --> K
    D --> K

The two-tier cache design reflects different freshness requirements: search results (hotel metadata, photos, ratings) change rarely and tolerate a 5-minute stale window; availability changes every few seconds during a booking wave and requires a 30-second cache with event-driven invalidation on every slot status change.

🛠️ Elasticsearch: How It Powers Hotel Search

Elasticsearch is the only open-source technology that can answer "all available rooms within 5 km of Times Square for December 31st, under $300 per night, for 2 guests" in under 200 ms at 10K QPS. The reason is its inverted index combined with first-class geospatial query support via the geo_point field type and the geo_distance filter.

Hotel listings are indexed as ES documents. Each document contains a location field of type geo_point, nightly price, guest capacity, and a multi-value keyword field named available_dates containing every open date for the next 12 months. A CDC pipeline (Debezium consuming PostgreSQL WAL events via Kafka) updates this field within 1–5 seconds whenever the Availability Service changes a slot status.

GET /hotels/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "geo_distance": {
            "distance": "5km",
            "location": { "lat": 40.7128, "lon": -74.0060 }
          }
        },
        { "range":  { "price_per_night": { "lte": 30000 } } },
        { "term":   { "max_guests": { "gte": 2 } } },
        { "terms":  { "available_dates": ["2025-12-31", "2026-01-01"] } }
      ]
    }
  },
  "sort": [
    {
      "_geo_distance": {
        "location": { "lat": 40.7128, "lon": -74.0060 },
        "order": "asc",
        "unit": "km"
      }
    },
    { "rating": { "order": "desc" } }
  ],
  "size": 20
}

The available_dates field in ES is an approximate indicator. It is kept reasonably fresh by the CDC pipeline but is not the authoritative source. The Availability Service always re-confirms availability from PostgreSQL at the start of the HOLD step. This prevents a guest from completing a booking based on stale ES data if the slot was booked in the 1–5 second CDC lag window.

For a full deep-dive on Elasticsearch indexing strategy, inverted index internals, and autocomplete design, see the companion post: System Design HLD Example: Search Autocomplete.

📚 Lessons Learned

• Check-then-act without a lock is always wrong for inventory. The TOCTOU race condition is the most common root cause of double-bookings. Model availability as a lockable database row with a version counter — not as a derived query result that any concurrent reader can also see as "available."
• Optimistic locking beats pessimistic locking for most booking systems. Room booking conflicts are rare in aggregate. OCC delivers high write throughput and degrades gracefully with retries. SELECT FOR UPDATE serialises all writes to a room and becomes a bottleneck precisely during the high-traffic windows when you can least afford it.
• The hold window is a product decision with architectural consequences. A 15-minute hold is long enough for checkout but short enough to limit ghost availability suppression. Hard-code it as a named constant (HOLD_DURATION_MINUTES = 15) and surface it as a tunable configuration value.
• Search and booking must run on separate data stores. Running 10K search QPS against the booking database creates read-write contention and slows availability writes during booking waves — exactly when correctness matters most.
• Every write API that crosses a network boundary needs an idempotency key. The idempotency_key UNIQUE constraint is the last line of defence: even if the Redis cache is cold, a duplicate booking attempt at the database layer returns a conflict row rather than creating a second confirmed booking.
• Model the payment lifecycle as two distinct phases. Pre-auth at hold creation; capture before check-in. This maps cleanly to the two-phase reservation model: a failed payment during the hold phase releases the slots without the guest ever seeing a charge.

📌 TLDR: Summary & Key Takeaways

• Date-level inventory slots — model each room-night as an independent availability_slots row with its own status and version; this is the foundation that makes per-night locking granular and efficient.
• Optimistic locking + UNIQUE constraint — @Version on the slot row prevents concurrent HOLDs from both succeeding; UNIQUE(room_id, slot_date) is the database-level backstop for any OCC gap.
• Two-phase reservation — HOLD (15-minute window) → payment pre-auth → CONFIRM; failure at any step releases the hold cleanly without stranded charges.
• Redis SETNX for hot listings — a front-door lock on contested (roomId, dateRange) keys prevents thundering-herd OCC conflicts on popular properties during peak booking windows.
• Separate search from booking — Elasticsearch for geo + date search at 10K QPS; PostgreSQL for ACID availability writes; never co-locate the two workloads.
• Idempotency key on every booking write — Redis 24 h cache + DB UNIQUE constraint together provide defence in depth against duplicate bookings from network retries.

📝 Practice Quiz

1. Why does the hotel booking system use optimistic locking rather than SELECT FOR UPDATE (pessimistic locking) for availability slots?

   • A) PostgreSQL does not support row-level locking
   • B) Optimistic locking provides higher write throughput because it never blocks concurrent readers; conflicts are rare in aggregate and handled by retry logic
   • C) SELECT FOR UPDATE cannot be used on tables with UUID primary keys Correct Answer: B

2. Three guests simultaneously submit booking requests for the same apartment on December 31st, which has exactly one availability_slots row for that date. What prevents all three from succeeding?

   • A) The API Gateway rate limiter blocks requests after the first one
   • B) The version column: only the first UPDATE that reads the original version succeeds; the other two return 0 rows affected and are retried or rejected
   • C) The Payment Service rejects duplicate pre-auth requests automatically Correct Answer: B

3. Why does the system use Elasticsearch for search rather than querying the PostgreSQL bookings database directly?

   • A) PostgreSQL cannot store latitude/longitude coordinates
   • B) The search-to-booking QPS ratio is approximately 20:1; co-locating 10K search QPS with ACID booking writes would cause read-write contention and degrade booking throughput precisely during booking waves
   • C) Elasticsearch automatically prevents double-bookings via its document versioning Correct Answer: B

4. Why must the booking API require a client-supplied Idempotency-Key header on POST /bookings?

   • A) To authenticate the guest and prevent anonymous bookings
   • B) To route the request to the correct regional availability replica
   • C) Network timeouts cause clients to retry; without idempotency the server would create a second confirmed booking from a retry of an already-succeeded request Correct Answer: C

5. Open-ended challenge: A guest completes checkout successfully. The Payment Service returns a pre-auth code. The Booking Service then crashes before it can UPDATE availability_slots to booked. The guest has a pre-auth charge on their card but no confirmed booking, and the slot remains in held status. Walk through the full recovery strategy: what data would you inspect, what does the background reconciliation job do, how do you prevent the guest from being permanently charged without a confirmed booking, and what invariant must hold at the end of recovery?

🔗 Related Posts on System Design

• System Design HLD Example: Payment Processing Platform
• System Design: Databases — SQL vs NoSQL and Scaling
• System Design: Caching and Asynchronism
• System Design: Sharding Strategy
• System Design HLD Example: Search Autocomplete