Design a Hotel Booking System

Problem High-level design of a hotel booking system — fetch hotels, check room availability, book — with the spotlight on concurrency: simultaneous requests must never double-book a room.

Functional requirements

• Search/fetch hotels with filters; check availability for (roomType, dateRange); book with payment; cancel.

Non-functional requirements

• Booking path strictly consistent; search read-heavy and cacheable; availability checks vastly outnumber bookings.

Key components

• Hotel/catalog service (cached, search-indexed); availability service reading room-night inventory; booking service owning the write path (hold → pay → confirm state machine, TTL on holds); payments; notifications.
• Inventory model: rows per (room_type, date) with available_count — bookings decrement across the date range in one transaction.

Deep dives — the concurrency core

• Pessimistic: SELECT … FOR UPDATE on the room-night rows, decrement, commit — simple, serializes hot rooms.
• Optimistic: version column, conditional UPDATE … WHERE available_count >= requested; retry on conflict — better under low contention.
• Constraint-as-backstop: CHECK (available_count >= 0) / unique (room_id, date) assignment so a race can't corrupt even with app bugs.
• Distributed hold layer (Redis SETNX + TTL) for cart-time reservations before payment; idempotency keys so client retries don't double-book; saga/compensation when payment fails after decrement.