# Booking.com Design
0) Problem Restatement
Design a scalable travel booking platform that allows billions of users to search, view, and book accommodations globally. The system must handle real-time inventory updates, dynamic pricing, and maintain strong consistency for booking and payment flows while serving low-latency search results.
1) Requirements
1.1 Functional
- Search Accommodations: By location, date, price, and various filters.
- Real-time Inventory: View up-to-the-minute availability and pricing.
- Booking & Payment: Securely book rooms with instant confirmation.
- Cancellations: Support user-initiated modifications and cancellations.
- Partner Portal: Allow hotels to manage and update inventory dynamically.
1.2 Non-Functional
- High Availability: Global reach with minimal downtime.
- Low Latency: Search results delivered in < 200ms.
- Strong Consistency: Critical for double-booking prevention and payments.
- Scalability: Handle millions of listings and multi-million concurrent users.
1.3 Scale Estimates
- Listings: 30 million properties.
- Daily Active Users: 20 million.
- Booking Requests: 100,000 per day.
- Search Queries: 10,000 requests/sec.
- Storage: Catalog data (TB), Inventory (In-memory), Archives (PB).
1.4 API Design
The core APIs required for the service:
- Search:
GET /v1/search- Filtered search for properties. - Get Availability:
GET /v1/properties/:id/availability- Check specific room status. - Create Booking:
POST /v1/bookings- Initiate a reservation. - Update Inventory:
PUT /v1/partners/inventory- Hotel partner update.
2) High-Level Architecture
2.1 Overview
- Search Service: Uses Elasticsearch for geo-spatial and text-based property discovery.
- Inventory Service: Manages real-time room availability using Redis for speed and SQL for durability.
- Booking Service: Orchestrates the transactional flow between inventory and payments.
2.2 Architecture Diagram
```mermaid
config:
layout: elk
flowchart LR
U[\