System Design of Airbnb Part 2 – Booking & Reservations, Payment, & Reviews & Ratings

Continuing the Journey: Delving into the Core Flow of Bookings, Secure Payments, and Community Trust Through Ratings & Reviews.

In Part 1 of this series, we focused on the foundational components—User Profiles, Listing Management, Search & Discovery, and Availability Service—that set the stage for an Airbnb-like platform.

In Part 2, we’ll tackle the next critical set of features:

1. Booking & Reservations – The mechanics of locking in dates, managing reservation details, preventing double bookings, and coordinating with the Availability Service.

2. Payment – Processing secure transactions, handling refunds, splitting payouts between the platform and the host, and integrating with payment gateways.

3. Reviews & Ratings – Fostering trust by allowing guests and hosts to share feedback and ratings, which also impacts future bookings.

Finally, in Part 3, we’ll discuss Messaging, Notifications, Trust & Safety, and Customer Support to complete our end-to-end system design.

---

1. Understand Question as User

We now want to design how users complete a booking on our Airbnb-like platform, make payments, and leave reviews:

1. Booking & Reservations:

   • Guests choose dates, confirm pricing, and finalize their reservation.

   • The system must prevent double bookings and maintain real-time alignment with the Availability Service.

2. Payment:

   • Integrates with external payment gateways to securely charge guests.

   • Supports multiple payment methods (credit card, PayPal, etc.).

   • Manages payouts to hosts, including platform fees and currency conversions.

3. Reviews & Ratings:

   • After the stay, guests can rate their experience and leave detailed reviews.

   • Hosts can also rate guests, promoting a two-sided trust system.

   • Reviews must be moderated for inappropriate content.

We’ll assume a scalable microservices design with high availability, security, and seamless integration among all services.

---

2. Requirement Gathering

2.1 Functional Requirements (FR)

Booking & Reservations

1. Initiate Booking: Guests can select listings, specify dates, confirm pricing, and request to book.

2. Reservation Workflow: Must handle pending, confirmed, and canceled statuses.

3. Sync with Availability: Once a reservation is confirmed, the listing’s availability must be updated.

4. Modification & Cancellation: Guests and hosts can cancel or change bookings under defined policies.

Payment

1. Secure Payments: Collect payment information (credit cards, digital wallets) and process transactions securely.

2. Payment Gateway Integration: Support popular gateways (Stripe, PayPal, Adyen, etc.) with fallback options.

3. Payout to Hosts: Distribute earnings to hosts minus service fees and taxes.

4. Refunds & Chargebacks: Handle partial or full refunds, and manage disputes/chargebacks.

5. Multi-Currency Support: Convert amounts based on user’s preferred currency or location.

Reviews & Ratings

1. Review Flow: Guests can leave reviews and star ratings after their stay. Hosts can optionally rate guests.

2. Public Display: Display average ratings and reviews on listing profiles.

3. Moderation: Detect and remove inappropriate, fraudulent, or spammy content.

4. Editing Window: Optionally allow a grace period for guests/hosts to edit or remove their reviews.

2.2 Non-Functional Requirements (NFR)

1. Scalability: Must handle peaks in booking traffic (e.g., holiday seasons) and payment processing.

2. High Availability: Payment and booking services require near-zero downtime to avoid transaction failures.

3. Security & Compliance: Must comply with PCI-DSS for payment handling, protect sensitive info with encryption.

4. Low Latency: Booking confirmation workflows should be near real-time.

5. Consistency: Avoid overbooking; booking states must remain consistent across services.

6. Resilience: Payment system should recover gracefully from gateway outages, with retry and fallback.

2.3 Out of Scope

• Detailed fraud detection (touched upon in Part 3 with Trust & Safety).

• Complex loyalty programs, coupons, or advanced pricing algorithms.

• Comprehensive customer support ticketing or escalation flows.

---

3. BOE Calculations/Capacity Estimations

While actual numbers vary based on usage, let’s do some back-of-the-envelope calculations for scale planning.

3.1 Booking & Reservations

1. Daily Bookings: Assume 500,000 bookings per day worldwide at peak times.

2. Peak QPS: 500,000 bookings/86,400 seconds≈5.8 bookings/sec

   1. Factor in surges (peak x4 or x5) → ~25–30 QPS for confirmed bookings. Actual read traffic for searching or checking booking details is much higher.

3. Data Storage:

   • Each booking record ~1 KB (reservation ID, user ID, listing ID, check-in, check-out, cost, status).

   • For 500,000 daily bookings, storing 365 days → ~182.5 million bookings/year: 182.5×10^6×1 KB≈182.5 GB/year

   • Implement archival strategy for older bookings.

3.2 Payment

1. Transactions: Typically each booking triggers a payment transaction. So ~500,000 transactions/day.

2. Payment Gateway Throughput: Must handle 6–7 transactions/second comfortably, with bursts up to 30–40 TPS.

3. Storage: Payment logs and audit trails are critical. Each record ~0.5–1 KB (transaction ID, user ID, amount, timestamp, gateway response). Over a year: ~182.5 million records → ~91–182 GB.

3.3 Reviews & Ratings

1. Reviews: Assume 50% of completed stays result in a guest review → ~250,000 reviews/day.

2. Average Review Size: ~300 bytes (rating, text snippet, user/listing references). For 365 days → ~91.25 million reviews/year = ~27 GB of data.

3. Read Load: Review read frequency can be high since each listing view might fetch recent reviews. Caching popular listing reviews is key.

3.4 Overall Considerations

• Microservices:

  • Booking Service must remain consistent with the Availability Service.

  • Payment Service depends on external gateways → plan for high concurrency, retries, and partial failures.

  • Reviews might be stored in a NoSQL DB for flexible text queries and easy indexing.

• Caching:

  • Real-time booking info might be ephemeral.

  • Payment states require strong consistency but can be cached with short TTL for status checks.

  • Reviews can be aggressively cached for listing pages with invalidation on new reviews.

---

4. Approach “Think-Out-Loud” (High-Level Design)

Key questions driving the design:

• How do we ensure no double bookings?

  • Must integrate with Availability Service using transactions and possibly distributed locks or optimistic concurrency.

• How do we handle partial failures in payments?

  • Use sagas or two-phase commits to roll back or confirm.

• How to manage trust in reviews?

  • Moderation and possible rating logic (guests can’t review if the stay is canceled, etc.).

Microservices

1. Booking Service: Orchestrates reservations, manages booking lifecycle, communicates with Availability.

2. Payment Service: Processes payments, integrates with external gateways, issues refunds.

3. Review Service: Stores and retrieves reviews and ratings, possible integration with a content moderation system.

Workflow

1. Booking Flow:

   • Guest requests to book → calls Booking Service → verifies availability → locks availability → if confirmed, triggers Payment → on success, finalizes booking.

2. Payment Flow:

   • Payment Service charges the guest’s card → if success, notifies Booking Service → if fail, reverts availability.

3. Review Flow:

   • After check-out date, system invites guest/host to leave a review → updates review store → possibly updates an overall rating cache for the listing.

---

5. Deep Dive into Core Services

A. Booking & Reservations Service

Responsibilities

1. Reservation Lifecycle: Initiate, confirm, modify, cancel.

2. No Double Booking: Ensure that once a booking is confirmed, the listing is blocked for those dates.

3. Collaboration with Availability: Real-time updates to the Availability Service.

4. Auditing & Tracking: Maintain an event log for booking states, used for analytics and dispute resolution.

Core Components

1. API Layer

   • Endpoints:

     • POST /bookings to create a new booking request.

     • PATCH /bookings/{id} to update booking status or dates.

     • GET /bookings/{id} for reservation details.

   • Integrates with load balancers and applies rate-limiting and auth checks.

2. Workflow Orchestrator

   • Coordinates Booking → Payment → Confirmation in a saga-style pattern.

   • On a successful payment event, transitions booking status from PENDING to CONFIRMED. If payment fails, reverts the status and frees up dates in Availability.

3. Data Store

   • Could be a relational DB (e.g., PostgreSQL) for strong consistency.

   • Table example: Bookingid PK, user_id, listing_id,status, check_in, check_out, amount, created_at, updated_at

4. Event Handling

   • Producer: Publishes booking change events to a queue (Kafka) for the Availability Service to update calendars.

   • Consumer: Listens for payment confirmation/failure events from the Payment Service.

Handling Corner Cases

1. Race Conditions:

   • If two guests try to book overlapping dates simultaneously, the first to finalize payment or lock availability wins. The second sees an error or alternative suggestions.

2. Booking Modifications:

   • If a guest changes dates, re-check availability for those new dates. If open, proceed; otherwise reject.

3. Failures in Payment:

   • Booking remains in PENDING_PAYMENT or FAILED state; availability is auto-reverted if not completed in time.

4. Cancellation Policies:

   • Partial refunds or penalty fees depending on rules.

   • Ensure transaction logs are consistent with the Payment Service.

---

B. Payment Service

Responsibilities

1. Secure Transactions: Charge the guest’s selected payment method.

2. Payouts: Transfer funds to the host’s account minus service fees and applicable taxes.

3. Refunds & Adjustments: Issue partial or full refunds on cancellations or disputes.

4. Compliance & Reporting: Payment logs for PCI-DSS compliance, auditing, taxes.

Core Components

1. API Layer

   • Endpoints for charging, refunds, payout status.

   • Must be PCI-DSS compliant if storing or even transiting credit card data. Ideally, use tokenization from payment gateways.

2. Payment Gateway Integrations

   • Adapters to multiple gateways (Stripe, PayPal, etc.) for fallback and geo-based payment solutions.

   • Retries & Idempotency: If a gateway times out, the service retries. Payment requests must be idempotent to avoid double-charging.

3. Transaction Manager

   • Manages state transitions: INITIATED → PROCESSING → SUCCESS/FAILED.

   • Uses a transaction log or outbox to ensure consistent updates to booking status.

4. Payout Module

   • Batch processes host payouts at intervals (daily, weekly) to reduce transaction fees.

   • Integrates with banks for direct deposits, or with e-wallet solutions in different regions.

5. Data Store

   • Could be a relational store, depending on read/write patterns.

   • Payment logs must be immutable or append-only for auditing.

Handling Corner Cases

1. Chargebacks & Disputes:

   • Payment Service must handle notifications from gateways about disputes.

   • Temporarily hold or claw back payouts if the booking is contested.

2. Multi-Currency:

   • Maintain exchange rate tables, possibly from a real-time FX service.

   • Store amounts in a base currency (e.g., USD) to unify accounting.

3. Payment Failures:

   • If a guest’s payment fails, send an immediate event to the Booking Service to keep or release the dates.

4. Offline or Delayed Payouts:

   • If a gateway is down, queue the payout request and retry later.

---

C. Reviews & Ratings Service

Responsibilities

1. Collect Reviews: Store text feedback, star ratings, and structured fields (cleanliness, communication, etc.).

2. Two-Sided Rating System: Allow hosts to rate guests to foster mutual trust.

3. Review Moderation: Filter out offensive or fraudulent content.

4. Aggregate Ratings: Compute overall rating for each listing and store in a quick-access cache or index.

Core Components

1. API Layer

   • Endpoints:

     • POST /reviews to create a new review.

     • GET /listings/{id}/reviews to fetch a listing’s reviews.

     • GET /user/{id}/reviews to fetch a user’s reviews if needed.

   • Validate that the guest actually completed a stay (booking in COMPLETED status) before accepting a review.

2. Review Database

   • NoSQL (e.g., Cassandra, MongoDB) for flexible document storage.

   • Records typically contain: Reviewid PK, booking_id, listing_id, user_id, rating, review_text, created_at, flagged?

3. Moderation & Flagging

   • Basic checks for profanity or spam.

   • Automatic or manual review of flagged content.

   • Possibly incorporate ML-based classifiers for toxicity detection.

4. Caching & Aggregation

   • Maintain average ratings in a separate table or in-memory cache to quickly show listing rating on search results.

   • Invalidate or recalculate the average rating each time a new review is added or removed.

Handling Corner Cases

1. Fake or Malicious Reviews:

   • Track repeated suspicious activity. In Part 3, we discuss advanced trust & safety mechanisms.

2. Review Editing:

   • Optionally allow a short window (24–48 hours) for editing or deleting.

   • Keep version history for auditing.

3. Large Volume:

   • Popular listings may have thousands of reviews. Paginate and index effectively.

4. Performance:

   • High read volumes for frequently viewed listings → rely on caching.

---

6. How to address Non-functional requirements (NFRs)

Below is a summary of the key non-functional requirements (NFRs) for (Booking & Reservations, Payment, and Reviews & Ratings) and the design strategies that address each requirement.

---

A. Scalability

• Horizontal Scaling of Microservices
  Each of the three core services—Booking, Payment, and Reviews—can be scaled independently by adding more instances behind a load balancer or through container orchestration (e.g., Kubernetes).

• Database Sharding / Replication

  • Booking DB: A relational database can be horizontally sharded or use read replicas to handle large volumes of write/read operations.

  • Payment DB: Transactions are typically write-heavy, so we can scale vertically (powerful DB nodes) or horizontally (sharding by payment ID).

  • Reviews DB: Using a NoSQL approach for flexible document storage scales horizontally as review volume grows.

• Message Queues
  Event-driven architectures (Kafka, RabbitMQ) decouple services. The system can handle spikes in booking confirmations or review creations without overloading downstream services.

---

B. High Availability

• Service Redundancy
  Each service is deployed in multiple instances or pods across different availability zones. If one instance fails, traffic automatically reroutes to healthy replicas.

• Database Replication & Multi-AZ
  Databases (relational or NoSQL) are deployed in a primary-replica or leader-follower model across multiple availability zones, ensuring minimal downtime during outages.

• Automated Failover
  Container orchestration (Kubernetes) restarts failed pods and can route traffic to another region if a zone becomes unavailable.

---

C. Performance / Low Latency

• Caching

  • Booking: Frequently accessed data (e.g., booking status) can be cached short-term to reduce DB hits.

  • Reviews: Heavily read data (listing reviews) can be cached to serve quick responses.

• Asynchronous Workflows

  • Moving non-critical tasks (e.g., sending notifications, computing aggregated ratings) to an asynchronous event queue reduces synchronous request latency.

• Efficient Data Models

  • Booking and Payment store concise, indexed records in relational DBs for fast lookups.

  • Reviews in NoSQL can query by listing or user ID efficiently.

---

D. Consistency

• Transactional Updates in Booking & Payment

  • Saga Pattern or orchestrated workflows ensure booking status and payment state do not drift (e.g., if payment fails, booking is canceled).

  • Optimistic Locking and idempotent endpoints handle duplicate or out-of-order requests.

• Eventual Consistency for Async Services

  • Systems like Reviews or Notifications can be eventually consistent, consuming booking/payment events from queues. Delays do not compromise core functionality.

---

E. Security & Compliance

• Payment Security

  • PCI-DSS Compliance: Storing or transmitting credit card data is handled securely (e.g., tokenization from payment gateways).

  • Use of HTTPS/TLS for all communication (client → gateway → microservice).

• Authorization & Authentication

  • API Gateway checks tokens or sessions before routing requests.

  • Role-Based Access Control ensures only hosts/guests can modify their respective data.

• Database Encryption

  • Sensitive columns in Payment DB (e.g., partial card details, transaction logs) are encrypted at rest.

---

F. Fault Tolerance & Resilience

• Circuit Breakers & Timeouts

  • Booking → Payment calls use circuit breakers to avoid cascading failures if the Payment Service or external gateway is down.

• Retry & Dead-Letter Queues

  • If any part of the system (e.g., Payment Gateway) fails temporarily, the request is retried with an exponential backoff.

  • Irrecoverable messages land in a dead-letter queue for manual inspection.

• Autoscaling

  • Microservices automatically scale up or down based on metrics like CPU usage, request throughput, or queue length.

---

G. Observability & Monitoring

• Centralized Logging & Metrics

  • Each service (Booking, Payment, Reviews) exports logs and metrics (success/failure rates, latencies) to a centralized system (e.g., ELK stack, Prometheus + Grafana).

• Alerting

  • Automated alerts trigger if error rates or response times exceed thresholds, enabling quick issue triage.

• Tracing

  • Distributed tracing (Jaeger, Zipkin) captures end-to-end latencies from the API Gateway through Booking/Payment/Reviews, aiding in root-cause analysis.

---

H. Global Reach (Optional)

• Multi-Region Deployments

  • For global user bases, each microservice (Booking, Payment, Reviews) can be deployed in multiple geographic regions.

  • A global load balancer or DNS-based routing sends users to the nearest region, reducing latency and providing failover if one region is offline.

---

Putting It All Together

1. Booking Flow

   • A guest initiates a booking → Booking Service checks availability → transitions to PENDING_PAYMENT.

   • Payment Service charges the user → on success, notifies Booking → Booking transitions to CONFIRMED and updates Availability.

2. Stay Completion & Review

   • After checkout, the Review Service prompts the guest.

   • Guest leaves a review, it’s persisted in the NoSQL DB, and aggregated rating is updated.

3. Key Integrations

   • Event-Driven architecture with Kafka or RabbitMQ to keep services in sync.

   • Shared logging and monitoring across Booking, Payment, Reviews for debugging and analytics.

---

Conclusion & Next Steps

In Part 2, we covered the critical paths that directly drive revenue (bookings and payments) and build community trust (reviews). Each service has distinct scaling, consistency, and security challenges:

• Booking & Reservations: Concurrency and real-time integration with availability are paramount to avoid double bookings.

• Payment: Must be secure, compliant, and robust against gateway failures and chargebacks.

• Reviews & Ratings: Key driver of trust—requires high-volume read handling, moderation, and efficient storage.

In Part 3, we’ll dive into the final pieces—Messaging System, Notifications, Trust & Safety, and Customer Support—to complete this end-to-end Airbnb-like system design. Stay tuned!