The Question
Design

Home Rental Marketplace

Design a home rental marketplace similar to Airbnb. The system should support property listings with availability calendars, geo-based search, booking management with payment processing, host and guest reviews, and real-time inventory updates to prevent double bookings at global scale.
PostgreSQL
Elasticsearch
Redis
Questions & Insights

Thinking Process

The core challenge of Airbnb is balancing a high-read Search & Discovery system with a high-consistency Booking & Reservation engine.
How do we handle efficient spatial queries? We use Geospatial indexing (Quadtrees or Google S2) within a search-optimized engine like Elasticsearch to filter listings by map coordinates and radius.
How do we prevent double-bookings? We must use a Relational Database (RDBMS) with ACID properties and a distributed locking mechanism (or database-level constraints) on the (ListingID, Date) tuple.
How do we handle the high read-to-write ratio? We decouple the Search path from the Booking path. Search uses an eventually consistent, indexed store, while Booking uses a strictly consistent source of truth.
How do we manage listing availability? We use a "Calendar" service that manages availability bitmasks to quickly check if a listing is free for a requested date range.

Bonus Points

Dual-Phase Commit / Saga Pattern: Implementing a Saga pattern for bookings to ensure that if the Payment service fails, the "reserved" status in the Booking service is rolled back gracefully.
Availability Bitmasks: Storing listing availability as a 365-bit long string or BLOB to allow for O(1) availability checks for any date range within a year.
Idempotency Keys: Using unique tokens for all booking and payment requests to prevent duplicate charges or reservations during network retries.
Geo-Sharding: Sharding the database by RegionID or CountryCode to improve query performance and comply with data residency laws (e.g., GDPR).
Design Breakdown

Functional Requirements

Users can search for listings by location, date range, and guest count.
Users can view listing details and photos.
Users can book a listing (Reservation).
Hosts can manage their listings and availability.

Non-Functional Requirements

High Consistency for Bookings: No double-bookings allowed.
Low Latency Search: Map-based search results must load in < 500ms.
High Availability for Discovery: Users should be able to browse even if the booking system is undergoing maintenance.
Scalability: Support 100M+ listings and millions of concurrent users.

Estimation

Total Listings: 5 Million.
Search Queries: 10,000 QPS (assuming 100M DAU and frequent map panning).
Booking Volume: 100,000 bookings per day (~1.1 per second, but highly bursty).
Storage (Images): 5M listings 20 images 1MB = 100 TB.
Metadata Storage: 5M listings * 5KB = 25 GB (Fits easily in most modern DB clusters).

Blueprint

Concise Summary: A microservices architecture that separates the read-heavy search flow (Elasticsearch) from the write-heavy, consistent booking flow (PostgreSQL).
Major Components:
Search Service: Uses geospatial indexing to return listings within a geographical boundary.
Listing Service: The source of truth for listing metadata and host information.
Booking Service: Manages the state machine of a reservation (Pending -> Paid -> Confirmed).
Calendar Service: Manages high-frequency availability updates and checks.
Simplicity Audit: We utilize a standard RDBMS for bookings to guarantee consistency, avoiding the complexity of distributed transactions across NoSQL nodes for the MVP.

High Level Architecture

Sub-system Deep Dive

Service

Topology & Scaling: Services are deployed as stateless microservices. The Search Service is scaled based on QPS, while the Booking Service is scaled more conservatively to manage DB connection pools.
API Spec:
GET /v1/search?lat=...&lon=...&radius=...&checkin=...&checkout=...
POST /v1/bookings: Requires an idempotency key and listing details.
PUT /v1/listings/{id}/availability: Updates the calendar bitmask.

Storage

Data Model:
Bookings Table (Postgres): booking_id (PK), listing_id (FK), guest_id, start_date, end_date, status (enum).
Unique Constraint: A partial index or exclusion constraint on listing_id and daterange to prevent overlapping bookings at the database level.
Database Logic: Master-Replica setup. Reads for listing details go to replicas; bookings go to the Master.

Cache

Implementation: Redis.
Data Structures:
String: Key avail:{listing_id}:{year}, Value: Bitmask of 365 bits.
Hash: Key listing:{id}, stores basic metadata for fast "Listing Detail" page loads.
Eviction: LRU (Least Recently Used) for listing metadata.

Messaging

Implementation: Kafka.
Topic Structure:
listing_updates: When a host changes a price or description, the Search Service consumes this to update the Elasticsearch index.
booking_events: Triggers confirmation emails, SMS, and push notifications.
Guarantees: At-least-once delivery with idempotent consumers.
Wrap Up

Advanced Topics

Trade-offs: Availability vs. Consistency. We choose strict consistency for bookings (Postgres) because a double-booking results in a terrible user experience. We choose high availability for search (Elasticsearch), meaning a newly created listing might take a few seconds to appear in search results (Eventual Consistency).
Bottlenecks: The primary bottleneck is the PostgreSQL master during peak booking seasons (e.g., New Year's Eve). We mitigate this by moving availability checks to the Calendar Service which uses Redis bitmasks before hitting the DB.
Failure Handling:
ES Index Failure: If Elasticsearch is down, the Search Service can fall back to a basic Postgres ST_Distance query for a limited geographical area.
Payment Timeout: Use a background worker to "reap" expired bookings (Pending status > 15 mins) to release the calendar slots.
Alternatives & Optimization:
Optimization: Use Google S2 Geometry for the search index. It maps a 2D sphere to a 1D Hilbert curve, allowing spatial queries to be treated as simple range queries in a key-value store.