E-Commerce Platform (Amazon, eBay)

Overview
Introduction
Designing an e-commerce system like Amazon is a complex challenge due to the vast array of services required in a production environment. However, given the time constraints of a technical interview, it’s critical to clarify with your interviewer which functionalities they expect to see implemented. In this solution, we focus on the core user-facing features - such as product browsing, shopping cart, and order processing - that most interviewers prioritize, while outlining a scalable and efficient design tailored to interview expectations.
Requirements
- Functional Requirements
- User Authentication: Enables login for cart persistence and order history.
- Product Catalog: Allows browsing by category and searching by keyword with key details (e.g., price, availability).
- Shopping Cart: Supports adding, updating, or removing items, persisted for logged-in users.
- Order Management: Facilitates order placement, history, and status tracking.
- Payment Processing: Supports multiple methods (e.g., credit card) and refunds securely.
- Inventory Management: Ensures real-time stock updates (reduce on order, increase on return).
- Non Functional Requirements
- Scalability: Handle millions of users and transactions (e.g., horizontal scaling with load balancers, sharded databases), and support traffic spikes (e.g., Black Friday sales) using auto-scaling and caching.
- Performance: Low latency for search and page loads (e.g., < 200ms for product searches), and fast checkout process to minimize cart abandonment.
- Availability: The system should be reliably accessible at all times, with minimal downtime (e.g., using redundancy, multi-region deployment).
- Security: Enforces encryption (TLS, HTTPS) and PCI DSS compliance.
- Not Covered
- The following features are typical in a production e-commerce system but are excluded here due to interview time constraints.
- Notifications: Email or SMS updates for orders and promotions (full notification system design here).
- Reviews and Ratings: User-generated product feedback.
- Seller Portal: Tools for third-party sellers to manage listings.
- The following features are typical in a production e-commerce system but are excluded here due to interview time constraints.
Estimates
In this section, we estimate Query Per Second (QPS) and storage needs for the e-commerce system with simplified back-of-the-envelope calculations, suitable for an interview’s time constraints.
- Assumption: 10M daily active users (DAU), with peak traffic 2x average
- Traffic Breakdown: Mostly browsing/search (~80%), some checkout (~20%)
- Calculation:
- 10M users/day × 10 page views/user = 100M views/day
- 100M / (24 × 3600 seconds) ≈ 1,150 QPS (average)
- Peak QPS = 1,150 × 2 = 2,300 QPS
- Assumption: 10M users, 100M products, 1M orders/day, 1-year retention
- Calculation:
- Users: 10M × 1KB/user = 10GB
- Products: 100M × 10KB/product = 1TB
- Orders: 1M/day × 5KB/order × 365 days = 1.825TB
- Total = 10GB + 1TB + 1.825TB ≈ 2.84TB
Note: These are simplified estimates for interview brevity. A more comprehensive analysis (e.g., splitting QPS by operation or factoring in replication) is more accurate but omitted here due to time constraints of an interview.
Data Model
The data model encapsulates the core entities required to support the e-commerce system’s functionality. It’s designed to be simple yet extensible for an interview setting.
- User: Authentication, personalization.
- Product: Catalog data.
- Inventory: Stock management (separate from products).
- Cart, CartItem: User shopping cart tracking.
- Order, OrderItem: Order details and inventory linking.
- Payment: Transaction details and tracking.
- User → Cart (One-to-One)
- Cart → CartItem (One-to-Many)
- Product → CartItem (Many-to-One)
- User → Order (One-to-Many)
- Order → OrderItem (One-to-Many)
- Product → OrderItem (Many-to-One)
- Order → Payment (One-to-One)
- Product → Inventory (One-to-One)
API Design
This API design outlines the core RESTful endpoints for the e-commerce system, focusing on the main user flows expected in an interview. All endpoints assume secure communication (HTTPS) and user authentication via a token (e.g., JWT in the Authorization header).
- POST /auth/login
- Authenticates user.
- Request: {"email": "user@example.com", "password": "password123"}
- Response (200): {"token": "jwt_token", "user_id": 123}
- GET /products?category_id=5&search=phone&page=1&limit=20
- Lists products with filters.
- Response (200): {"products": [{"id": 1, "name": "Smartphone", "price": 699.99}], "total": 100}
- POST /cart/items
- Adds item to cart.
- Request: {"product_id": 1, "quantity": 2}
- Response (201): {"message": "Item added"}
- POST /orders
- Places order.
- Request: {"payment_method": "credit_card", "shipping_address": "123 Main St"}
- Response (201): {"order_id": 789, "total_amount": 1399.98}
- POST /orders/{id}/pay
- Processes payment.
- Request: {"payment_token": "token"}
- Response (200): {"payment_id": 101, "status": "completed"}
Product Browsing Flow
- Client App
- User Action: The user sends a request to browse products via GET /products?search=smartphone
- API Gateway
- Routing: The API Gateway receives the request, authenticates the user, applies rate limiting, and forwards the request to the Product Service.
- Additional Functionality:
- Authentication and Authorization: Verifies the JWT token.
- Rate Limiting: Prevents abuse by limiting the number of requests per user.
- Load Balancing: Distributes requests across multiple instances of the Product Service using a Round Robin approach for optimal load distribution.
- Product Service
- Elastic Search: Queries an Elasticsearch index for product metadata. Elasticsearch is used due to:
- Full-text search capabilities (keyword, category filters).
- Typo tolerance and low latency (<200ms).
- Horizontal scalability to millions of products.
- Redis: Caches frequently accessed product metadata (read-heavy data) with a short TTL (e.g., 5 minutes), reducing latency and load on Elasticsearch.
- Inventory Service: Independently called by the Product Service to fetch real-time stock data.
- Maintains accurate stock counts.
- Utilizes a strongly consistent store (e.g., Cassandra with Lightweight Transactions, PostgreSQL, or Redis locks) to prevent overselling and ensure atomicity, especially critical during high-traffic periods (e.g., Black Friday). Cassandra is a great option here with its blend of high write performance, horizontal scalability, tunable consistency, and built-in atomicity via LWT makes it an ideal choice for the Inventory Service. It excels in high-traffic, write-heavy scenarios, ensuring stock accuracy without sacrificing availability, so it is perfect for a robust e-commerce browsing flow.
- Response: Product Service aggregates the search results (from Elasticsearch/Redis) with stock data (from Inventory Service) and returns: {"products": [{"id": 1, "name": "Smartphone", "price": 699.99, "stock_quantity": 50}]}.
- Elastic Search: Queries an Elasticsearch index for product metadata. Elasticsearch is used due to:
Cart Management Flow
Checkout and Order Placement Flow
Complete Architecture
Additional Discussion Points
Master System Design Interviews
Get ready for the exact system design questions top tech companies are asking right now. Read comprehensive editorial write-ups and practice with our AI whiteboard that simulates a real, step-by-step interviewer experience.
See All System Designs →