Design a Hotel Booking Website

Problem Design the backend for a hotel booking website: search hotels/rooms, book and unbook, retrieve a user's bookings. Then evolve the design for two follow-ups: booking updates arriving from a dependency via Kafka, and 10x holiday-season scale.

Functional requirements

• Search by location/dates/filters returning available rooms with prices; create/cancel bookings; list a user's bookings.

Non-functional requirements

• No double-booking (consistency on the write path); search read-heavy and cacheable; baseline scale to state, then 10x seasonal spike.

Key components

• Search service over an indexed read model (Elasticsearch/cache) fed from the inventory store; inventory + booking service (transactional DB, room-night availability rows); user-bookings query API; payment integration.
• Booking write path: check availability → hold (TTL) → confirm within a transaction or with optimistic version checks; idempotency keys on create/cancel.

Deep dives / trade-offs

• Kafka follow-up: consume dependency updates through a consumer group; idempotent, out-of-order-tolerant handlers (version/timestamp per room-night); outbox on our own writes so internal and external updates flow through one pipeline; DLQ + replay for poison messages.
• 10x follow-up: scale reads first (cache search results and hotel pages, CDN, read replicas), partition inventory by hotel/region, queue booking writes to absorb bursts, autoscale stateless tiers, load-shed low-value traffic (bots/scrapers), pre-warm caches before the season.
• Overbooking policy discussion: strict locking vs small deliberate oversell with reconciliation.