Design a Hotel Booking System — System Design Interview Practice

Interview prompt

Design a hotel reservation platform that searches location and date availability, holds rooms, accepts payment, confirms bookings, and prevents double booking across channels.

• Model room inventory by property, room type, date, rate plan, and hold/booking state rather than caching a single availability number.
• Use a short-lived hold and conditional inventory transaction before payment capture, with an explicit expiry and recovery path.
• Make confirmation, cancellation, payment callbacks, and partner-channel retries idempotent and auditable.
• Explain overbooking policy, timezone boundaries, stale search results, refunds, inventory reconciliation, and fraud controls.

Requirements and scale assumptions

• Search properties and rates by location and dates, inspect policies, place a temporary hold, pay, and confirm a reservation.
• Support cancellations, modifications, refunds, partner inventory updates, guest identity, and booking notifications.
• Expose availability freshness, hold expiry, payment state, confirmation code, inventory audit, and reconciliation status.
• Never oversell a room inventory unit unless an explicit property overbooking policy permits it.
• Handle high concurrency by partitioning inventory by property and date and isolating popular hotels and event dates.
• Make holds, payment authorization, confirmation, cancellation, and partner callbacks idempotent.
• Return a pending payment or unavailable state rather than confirming when inventory or processor state is uncertain.
• Search 10 million properties and process 100,000 booking attempts per minute during travel and event peaks.
• Partition by property, room type, and stay date; isolate hot properties and aggregate search caches separately.
• Retain inventory ledgers, holds, payments, confirmations, partner messages, and reconciliation evidence.

• Booking attempts: 100K/min peak — Drives inventory partitions, hold capacity, payment limits, and partner-channel queues.
• Inventory correctness: No duplicate sell — Correct conditional inventory transitions matter more than serving a stale search result quickly.
• Durable boundary: Committed before async — The source of truth is Search hotels by location and dates; Check room availability in real-time.
• Async boundary: At-least-once workers — Keep Optimistic or pessimistic locking, Database transactions for booking, Inventory management system off the synchronous path.

Key entities

• ReservationIntentintentId, customerId, offerId, status, version, idempotencyKey

  Idempotent hotel booking system reservation intent with an explicit lifecycle.

• InventoryClaimclaimId, itemId, quantity, expiresAt, status, version

  Short-lived conditional claim that protects scarce availability.

• PaymentAttemptattemptId, intentId, provider, requestHash, status, providerRef

  Retry-safe payment attempt with unknown-outcome reconciliation.

• FulfillmentStateintentId, stage, owner, lastEventId, status, updatedAt

  Durable downstream reservation fulfillment progress.

Data flow

1. 1. Search and price current candidatesThe hotel booking system query path combines catalog, eligibility, price, and current availability without treating a stale index as a final claim.
2. 2. Claim scarce inventoryThe hotel booking system service creates a short-lived conditional claim keyed by item and request idempotency before charging or confirming.
3. 3. Confirm the reservation safelyPayment, policy, and inventory transitions are versioned; unknown provider outcomes are reconciled before retry.
4. 4. Publish fulfillment workThe committed hotel booking system intent emits an event for partner, packing, delivery, or campaign dispatch workers.
5. 5. Expire, cancel, and reconcileExpiry and cancellation release claims idempotently while reconciliation compares internal state with external providers or partners.

Deep dives and trade-offs

• Inventory claims and oversell controlUse conditional writes or a serialized inventory partition for hotel booking system scarce capacity. Give holds an expiry and reaper, but never release a confirmed claim from a stale worker. Separate searchable availability from the authoritative claim path.
• Payment and unknown outcomesBind hotel booking system payment attempts to the intent and request hash, not just the customer session. Treat timeout as unknown, query or reconcile provider state, and avoid a blind second charge. Keep sensitive payment tokens outside business records and logs.
• Fulfillment and partner recoveryPublish hotel booking system events after commit, consume at least once, and track per-stage progress. Use reconciliation against partner feeds or delivery evidence instead of assuming a callback arrives. Expose pending and expired status so the client can explain what happened.
• Reservation versus oversell tolerancePrefer a short-lived hotel booking system claim for scarce inventory and state the consistency scope explicitly. A cache or search index cannot safely decrement the final room count.
• Synchronous checkout versus asynchronous fulfillmentCommit the reservation intent synchronously and move partner or delivery work behind events. Waiting for downstream fulfillment makes retries ambiguous and increases checkout tail latency.
• Precompute availability versus compute at read timePrecompute common search dimensions but validate the final claim against authoritative state. Serving only a precomputed hotel booking system availability view creates oversell or stale-price failures.