Design expedia

Reference Answer

For a full example answer with detailed architecture diagrams and deep dives, see our Design Payment System guide. While the payment guide focuses on transaction processing, many of the same patterns around multi-step workflows, contention handling, and ACID guarantees apply directly to hotel booking flows where payment authorization and inventory updates must be coordinated atomically.

Also review the Search, Caching, and Databases building blocks for background on faceted hotel search, availability caching, and transactional inventory management.

Problem Statement

Design a hotel booking platform similar to Expedia that allows users to search for and book accommodations at various hotels including chains like Hilton and boutique properties. For simplicity, focus on a single metropolitan area. Users enter dates, filter by price and amenities, see real-time availability and pricing, and complete a booking with payment and confirmation.

The core challenges are handling contentious inventory where multiple users compete for the same room on the same dates, keeping search fast and fresh while availability changes constantly, and orchestrating a multi-step booking workflow that coordinates soft holds, payment authorization, hotel confirmation, and final booking. A poor design leads to double-bookings, stale search results, or lost payments. Interviewers want to see how you prevent overselling under load, make pragmatic consistency and caching tradeoffs, and design a booking saga with idempotent failure handling.

Key Requirements

Functional

• Hotel search -- users search hotels by dates, price range, star rating, amenities, and keywords, with results sorted by relevance, price, or rating
• Availability and pricing -- the system shows real-time room types, current prices, and availability for the selected dates at each hotel
• Reservation creation -- users book a specific room type, pay securely, and receive an instant confirmation with a reservation ID
• Reservation management -- users can view, cancel, or modify existing reservations subject to hotel cancellation policies

Non-Functional

• Scalability -- support 10,000 concurrent users across 500 hotels averaging 100 rooms each; handle 50,000 searches per minute during peak hours
• Reliability -- zero double-bookings under contention; 99.9% uptime for booking transactions; graceful degradation if partner systems are unavailable
• Latency -- search results within 500ms; complete booking checkout within 3 seconds end-to-end including payment authorization
• Consistency -- strong consistency for inventory decrements and payment captures; eventual consistency for search indexes updated every 30-60 seconds

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Inventory Contention and Double-Booking Prevention

Hotels have finite room inventory that multiple users compete for simultaneously. This is the most critical correctness challenge.

Hints to consider:

• Use optimistic locking with version numbers on inventory records per (hotel_id, room_type, date) to detect concurrent modifications before committing
• Implement Redis-based soft holds with 5-10 minute TTLs to temporarily reserve inventory during checkout without blocking other users from browsing
• For the final booking commit, use a database-level atomic decrement with a check constraint (available_count >= 0) to guarantee no overselling
• Generate idempotency keys per booking attempt so retries do not create duplicate reservations or double-charge users

2. Search Performance and Freshness

Search is the highest-traffic operation and must join hotel metadata with dynamic availability data while staying fast and reasonably current.

Hints to consider:

• Store static hotel metadata (name, location, amenities, photos, ratings) in Elasticsearch for fast faceted search and text matching
• Cache availability and pricing data in Redis with short TTLs (1-5 minutes) and hydrate search results by joining hotel IDs from Elasticsearch with cached availability
• Pre-aggregate availability at the room-type level rather than individual room instances to reduce cache size and query complexity
• Implement a CQRS pattern where search queries hit an optimized read model completely separate from the transactional booking write path

3. Multi-Step Booking Workflow

A booking is not a single atomic operation: it involves a soft hold, payment authorization, hotel system confirmation, payment capture, and notification. Any step can fail.

Hints to consider:

• Use a saga or workflow orchestration pattern with explicit compensating actions: if payment authorization succeeds but hotel confirmation fails, automatically void the authorization
• Store an idempotency token with each external API call (payment gateway, hotel PMS) so retries do not create duplicate side effects
• Implement two-phase payment: authorize first, then capture only after hotel confirmation succeeds, avoiding the need for refunds on booking failures
• Provide users with real-time status updates during the checkout flow and define clear timeout policies with exponential backoff for each external dependency

4. Data Model for Availability and Pricing

How you model room inventory directly impacts query performance and booking correctness. Interviewers want to see a schema that supports efficient date-range queries.

Hints to consider:

• Create an inventory table with rows per (hotel_id, room_type, date) storing available_count, price, and version for optimistic locking
• Use the date as part of a composite index to enable fast range scans for check-in to check-out windows
• Denormalize the price and availability snapshot at booking time into the reservation record so the system preserves what the user saw and agreed to pay
• Batch inventory updates from hotel systems and use eventual consistency for search caches while maintaining strong consistency for the actual booking transaction

Suggested Approach

Step 1: Clarify Requirements

Confirm scope and constraints. Ask about the number of hotels and rooms to determine whether a single database instance is sufficient. Clarify whether you integrate with real hotel property management systems or own the full inventory. Verify booking cancellation and modification policies. Establish peak traffic expectations (searches per second, bookings per minute) and latency targets for search versus booking. Confirm whether the single-location scope means one city or one region.

Step 2: High-Level Architecture

Sketch the architecture: a Search Service backed by Elasticsearch for hotel metadata with faceted filtering and ranking; an Availability Service that queries inventory data from PostgreSQL and maintains Redis caches of room availability by date; a Booking Service that orchestrates the reservation saga including soft holds, payment authorization, and confirmation; and a Payment Service wrapping a third-party gateway. Add an API Gateway for routing and rate limiting. Show how search flows: user query hits the Search Service for hotel IDs, then the Availability Service hydrates pricing and availability via cached lookups. For bookings, illustrate the flow from soft hold creation in Redis through payment authorization to final inventory decrement in PostgreSQL with a workflow orchestrator managing the saga.

Step 3: Deep Dive on Inventory Management

Walk through how a booking atomically decrements room inventory. Describe the schema: an inventory table with (hotel_id, room_type, date, available_count, version). When a user starts checkout, create a soft hold in Redis with a unique hold_id and 10-minute TTL. When the user submits payment, authorize the payment first, then attempt the inventory decrement using optimistic locking: read the current version, decrement available_count, and commit only if the version matches. If another booking changed the version, return a "room no longer available" error and void the payment authorization. On success, record the reservation, publish a confirmation event, and release the Redis soft hold. Abandoned checkouts release holds via TTL expiration. Discuss edge cases: network partition during the final decrement, how idempotency keys prevent duplicate bookings on retry, and periodic reconciliation jobs comparing PostgreSQL inventory totals with Redis cache.

Step 4: Address Secondary Concerns

Cover search scaling: shard Elasticsearch by hotel location and use read replicas for availability queries. Discuss caching: cache availability at room-type granularity, use presence caches to quickly reject queries for fully booked hotels. Address monitoring: track inventory discrepancies, booking success rates, search latency percentiles, and payment failure rates. Cover payment failure handling: automatic retry with exponential backoff, user notification, and manual resolution queue. Mention security: PCI compliance for payment data, rate limiting to prevent inventory scraping and booking bots. Outline extensibility: supporting multiple cities via geographic partitioning, dynamic pricing based on demand signals, and integration with external hotel APIs.

Real Interview Quotes

"Design a system like Expedia where we can book hotels like Hilton or boutique hotels. For the sake of the conversation, we can keep it to only one location."

Related Learning

• Payment System -- saga patterns, idempotent payment processing, and two-phase authorization
• Yelp -- location-based search, faceted filtering, and caching for discovery platforms
• Search Systems -- Elasticsearch for hotel metadata and faceted availability queries
• Caching -- Redis for soft holds, availability caching, and rate limiting
• Databases -- PostgreSQL for transactional inventory management with optimistic locking