Design a large-scale Order Processing Platform

Question

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

Codemia · Accepted Answer

### Functional Requirements
- **Order Creation**: Users should be able to place orders via a REST API. Each order must include user details, product details, and payment information.
- **Order Status Tracking**: Users should be able to check the status of their orders in real time.
- **Order Cancellation**: Users can cancel orders before they are processed.
- **Admin Dashboard**: Admins should have access to analytics on order volume, revenue, and user activity.

### Non-Functional Requirements
- **Scalability**: The system must handle up to 10,000 orders per second (QPS) during peak times.
- **Availability**: The system should maintain 99.9% uptime.
- **Consistency**: Strong consistency for order processing to prevent duplication or data loss.
- **Latency**: The end-to-end processing time for an order should not exceed 200 ms.

### Back-of-Envelope Calculations
- **Daily Orders**: Assuming peak load of 10,000 QPS, the total number of orders can reach:
  - 10,000 orders/second x 60 seconds/minute x 60 minutes/hour x 24 hours/day = 864 million orders/day.
- **Data Storage**: Each order may average around 1 KB of data. Thus, daily storage requirements would be:
  - 864 million orders x 1 KB = 864 GB/day.
- **Monthly Storage**: For a month, this results in approximately:
  - 864 GB x 30 days = 25.92 TB of order data.
- **Bandwidth**: If each order requires 2 KB for processing (including metadata), the bandwidth needed is:
  - 10,000 orders/second x 2 KB = 20 MB/second.

### Component Diagram
- **API Gateway**: NGINX or AWS API Gateway for handling incoming requests and routing to appropriate services.
- **Order Service**: Microservice responsible for creating, updating, and retrieving orders (using Node.js).
- **Database**: PostgreSQL for strong consistency with replication across multiple regions for availability.
- **Caching Layer**: Redis for caching frequently accessed order statuses to reduce database load.
- **Message Queue**: Apache Kafka for asynchronous processing of order events (e.g., payment processing).
- **Load Balancer**: AWS Elastic Load Balancer for distributing incoming requests across multiple instances.

### Schema Design
- **Orders Table**:
  - `order_id` (UUID, Primary Key)
  - `user_id` (UUID, Foreign Key)
  - `product_id` (UUID, Foreign Key)
  - `status` (ENUM: 'pending', 'completed', 'canceled')
  - `created_at` (TIMESTAMP)
  - `updated_at` (TIMESTAMP)
  - `total_price` (DECIMAL)

### Access Patterns
- **Order Creation**: Write-heavy access pattern on the Orders table.
- **Order Status Retrieval**: Read-heavy pattern requiring efficient indexing on `order_id` and `status`.

### Architectural Decisions
- **Consistency vs. Availability**: Chose strong consistency for order processing to prevent duplicate orders, which may affect availability during high load. This is crucial for a financial transaction platform.
- **Database Choice**: Opted for PostgreSQL for its ACID compliance and support for complex queries, which is essential for maintaining order integrity.
- **Caching Strategy**: Implemented Redis to alleviate load on the database, but with a trade-off of eventual consistency on cached data (e.g., recent order statuses).
- **Partitioning Strategy**: Implemented horizontal sharding based on user_id to distribute load evenly across database nodes, improving performance but adding complexity in handling cross-shard queries.

Design a large-scale Order Processing Platform

SentinelOne

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

SentinelOne 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