Design a Order Processing Service

Question

Design a distributed order processing system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements
1. **Order Creation**: Users can create orders for hotel bookings, including details like user ID, hotel ID, check-in and check-out dates, and payment information.
2. **Order Retrieval**: Users can retrieve their order details using an order ID or user ID.
3. **Order Status Update**: The system must allow updates to order statuses (e.g., confirmed, cancelled).
4. **Payment Processing**: Integration with payment gateways for processing payments securely.
5. **Notification System**: Users receive notifications for order confirmations and updates.

### Non-Functional Requirements
1. **Scalability**: The system should handle millions of requests per day, with the ability to scale horizontally.
2. **Availability**: The system should aim for 99.99% uptime to ensure users can book at any time.
3. **Consistency**: Strong consistency is required for order processing to ensure that no double bookings occur.
4. **Latency**: The system should respond to user requests within 200 milliseconds under normal load.
5. **Security**: All sensitive data should be encrypted, and user authentication must be robust.

### Back-of-Envelope Calculations
1. **User Base**: Assume Booking.com has around 100 million active users.
2. **Order Frequency**: If each user books 1 order per year on average, this results in approximately 100 million orders per year.
3. **Peak Load**: During peak seasons (e.g., holidays), assume a 10x increase in bookings, leading to about 1 million orders per day.
4. **Request Handling**: If we consider a 10% conversion rate from browsing to booking, this results in 10 million browsing requests on peak days, translating to about 115 orders per second (1 million orders / 86400 seconds).
5. **Database Throughput**: Each order will involve multiple read/write operations, leading to a need for a database that can handle at least 500 transactions per second to accommodate both reads and writes.

### Component Diagram
- **API Gateway**: Acts as the entry point for all client requests, providing load balancing and request routing.
- **Order Service**: Handles the business logic for creating, retrieving, and updating orders. This service will be stateless and can be scaled horizontally.
- **Payment Service**: Responsible for processing payments, integrating with external payment gateways (e.g., Stripe or PayPal).
- **Database**: A distributed database like Amazon DynamoDB or Google Cloud Spanner for order data, chosen for scalability and high availability.
- **Notification Service**: Uses a message queue (e.g., AWS SQS) to send notifications post-order processing.
- **Monitoring & Logging**: Implement tools like Prometheus for monitoring and ELK stack for logging errors and analyzing system performance.

### Schema Design
- **Orders Table**:  
  - `order_id` (Primary Key, UUID)  
  - `user_id` (Foreign Key, UUID)  
  - `hotel_id` (Foreign Key, UUID)  
  - `status` (ENUM: confirmed, cancelled, pending)  
  - `check_in` (DATE)  
  - `check_out` (DATE)  
  - `payment_status` (ENUM: paid, pending, failed)  
  - `created_at` (TIMESTAMP)  
  - `updated_at` (TIMESTAMP)  
- **Users Table**:  
  - `user_id` (Primary Key, UUID)  
  - `email` (STRING, UNIQUE)  
  - `hashed_password` (STRING)  
  - `created_at` (TIMESTAMP)

### Access Patterns
- **Read Operations**: Fetching order details or user orders by `user_id` must be efficient. Indexing on `user_id` will facilitate this.
- **Write Operations**: Creating and updating orders must be atomic to maintain consistency.

### Architectural Decisions
1. **Consistency vs. Availability**: Given the need for strong consistency in order processing, we may choose synchronous writes to the database, which could impact availability during peak loads. A potential approach is to implement a fallback mechanism with eventual consistency for less critical operations.
2. **Database Selection**: Choosing a NoSQL database (DynamoDB) for its horizontal scalability and low latency, but with the trade-off of managing complex queries and joins that may need to be handled at the application level.
3. **Caching**: Implementing caching (using Redis) for frequently accessed data (e.g., hotel details) to reduce database load and improve read latency, at the cost of data staleness.
4. **Microservices**: Using a microservices architecture introduces operational complexity (e.g., service communication, deployment) but provides better separation of concerns and scalability for different components.
5. **Monitoring**: Investing in comprehensive monitoring and alerting tools (like Prometheus and Grafana) to track system performance and availability, which may add to operational overhead but ensures proactive issue resolution.

Design a Order Processing Service

Booking.com

What the Interviewer Expects

Key Topics to Cover

How to Approach This

Possible Follow-up Questions

Practice a Similar Problem on Codemia

Sample Answer

Requirements

Functional Requirements

Capacity Estimation

Back-of-Envelope Calculations

Submit Your Answer

Booking.com Software Engineer Interview Guide

Related Questions

Design a high-throughput Inventory Management System

Design a low-latency Rate Limiting System

Design a fault-tolerant Payment System

Design a fault-tolerant Messaging System

Design Walmart Product Search