Loading learning content...
Amazon processes over 4,000 orders per minute globally. Its product catalog contains more than 350 million unique items. During peak events like Prime Day, the platform handles hundreds of millions of customer visits in a single day, with shopping carts being created, modified, and abandoned at staggering rates. Every second of latency in checkout directly translates to millions of dollars in lost revenue.
Designing an e-commerce system at this scale isn't just about making products appear on a screen—it's about orchestrating a symphony of distributed systems that must work in perfect harmony: catalog services, inventory management, shopping cart persistence, payment processing, order fulfillment, and real-time recommendations.
This module will take you through the complete architecture of a system like Amazon, starting with what every great system design begins with: understanding the requirements.
By the end of this page, you will have a comprehensive understanding of the requirements—both functional and non-functional—for building an e-commerce platform at massive scale. You'll learn to think like a Principal Engineer scoping a system that must handle billions of operations daily while maintaining sub-second response times.
Before diving into specific requirements, we need to understand what makes e-commerce uniquely challenging from a system design perspective. E-commerce platforms sit at the intersection of multiple complex domains:
High-Read, High-Write Workloads: Unlike social media (read-heavy) or banking (write-heavy), e-commerce demands excellence in both. Product browsing generates massive read traffic, while cart operations, orders, and inventory updates create significant write pressure.
Real-Time Consistency Requirements: When a customer adds the last item in stock to their cart, the system must ensure they actually get it—not someone else who clicked a millisecond later. Yet strict consistency at global scale is architecturally expensive.
Financial Transactions: Unlike content platforms where occasional errors are tolerable, e-commerce involves real money. A bug that charges a customer twice or ships incorrect inventory creates legal liability and destroys trust.
Variable Traffic Patterns: E-commerce traffic is notoriously spiky. Black Friday can bring 20x normal traffic within minutes. The system must scale elastically while maintaining performance.
Understanding user journeys is essential for requirements gathering. Each journey maps to specific system capabilities that must be designed and optimized. Let's trace through the complete customer experience:
At each step of the journey, some percentage of customers drop off. This is the 'conversion funnel.' System design directly impacts conversion—every 100ms of checkout latency can reduce conversion by 1%. Understanding these journeys isn't just academic; it's directly tied to revenue.
Functional requirements describe what the system must do. For an e-commerce platform, we can organize these into three major subsystems: Product Catalog, Shopping Cart, and Checkout/Order Processing.
| Requirement ID | Requirement | Priority | Complexity |
|---|---|---|---|
| CAT-001 | Display product details including title, description, images, price, variants | P0 | Medium |
| CAT-002 | Support product search with full-text search and filters | P0 | High |
| CAT-003 | Organize products into hierarchical categories and subcategories | P0 | Medium |
| CAT-004 | Support product variants (size, color, configuration) | P0 | High |
| CAT-005 | Display product availability and estimated delivery date | P0 | High |
| CAT-006 | Show customer reviews and aggregate ratings | P1 | Medium |
| CAT-007 | Support multi-language product content | P1 | Medium |
| CAT-008 | Enable seller product listings with approval workflow | P1 | High |
| CAT-009 | Display dynamic pricing (sales, bulk discounts) | P0 | High |
| CAT-010 | Show related products and recommendations | P1 | High |
| Requirement ID | Requirement | Priority | Complexity |
|---|---|---|---|
| CART-001 | Add items to cart with selected variants and quantity | P0 | Medium |
| CART-002 | Update item quantities in cart | P0 | Low |
| CART-003 | Remove items from cart | P0 | Low |
| CART-004 | Display cart total with itemized breakdown | P0 | Medium |
| CART-005 | Persist cart across sessions and devices for authenticated users | P0 | High |
| CART-006 | Merge guest cart with authenticated user cart on login | P1 | High |
| CART-007 | Save items for later without removing from consideration | P1 | Medium |
| CART-008 | Display real-time inventory warnings for low-stock items | P0 | High |
| CART-009 | Apply promotional codes and validate discount eligibility | P0 | High |
| CART-010 | Show estimated shipping cost based on default/selected address | P1 | Medium |
| Requirement ID | Requirement | Priority | Complexity |
|---|---|---|---|
| CHK-001 | Capture and validate shipping address | P0 | Medium |
| CHK-002 | Calculate shipping costs based on items, destination, and speed | P0 | High |
| CHK-003 | Calculate taxes based on destination jurisdiction | P0 | High |
| CHK-004 | Process payments through multiple payment methods | P0 | High |
| CHK-005 | Validate and reserve inventory during checkout | P0 | Critical |
| CHK-006 | Generate order confirmation with unique order ID | P0 | Medium |
| CHK-007 | Send order confirmation via email/SMS | P0 | Low |
| CHK-008 | Support guest checkout without requiring account creation | P1 | Medium |
| CHK-009 | Handle payment failures gracefully with retry options | P0 | High |
| CHK-010 | Support multiple shipping addresses per order (split shipments) | P2 | High |
P0: Must have for launch, no exceptions. P1: Highly important, should be in launch if possible. P2: Desirable, can be phased in post-launch. In interviews, always clarify priorities with your interviewer—this demonstrates product sense.
Non-functional requirements (NFRs) describe how the system must perform. For Amazon-scale e-commerce, these are not nice-to-haves—they're fundamental constraints that shape every architectural decision.
Before designing any system, we must understand its scale. Let's work through the numbers for an Amazon-scale e-commerce platform. These calculations inform capacity planning and help identify bottlenecks before they occur.
12345678910111213141516171819202122232425
=== TRAFFIC ESTIMATION === Daily Active Users (DAU): 500 millionAverage Sessions per User per Day: 1.5Page Views per Session: 8 Total Daily Page Views: 500M × 1.5 × 8 = 6 billion page views/dayQueries Per Second (QPS): 6B / 86,400 = ~70,000 QPS (average)Peak QPS: 5× average = ~350,000 QPS === CART OPERATIONS === Users who add to cart: 30% of sessionsItems added per cart session: 3.5 (average)Cart add operations per day: 500M × 1.5 × 0.30 × 3.5 = ~790 million Cart QPS: 790M / 86,400 = ~9,100 QPS (average)Peak Cart QPS: 5× average = ~45,000 QPS === ORDER VOLUME === Conversion Rate: 2.5% of sessions result in orderOrders per Day: 500M × 1.5 × 0.025 = ~18.75 million orders/dayOrders Per Second: 18.75M / 86,400 = ~217 orders/second (average)Peak Orders Per Second: 10× average during events = ~2,200 OPS12345678910111213141516171819202122232425262728293031
=== CATALOG STORAGE === Total Products: 350 millionAverage Product Data Size: 50 KB (text, attributes, metadata)Total Catalog Storage: 350M × 50 KB = 17.5 TB Product Images per Product: 8 (average)Average Image Size: 500 KB (optimized)Total Image Storage: 350M × 8 × 500 KB = 1.4 PB === CART STORAGE === Active Carts (30-day active): 200 millionAverage Cart Size: 2 KB (item references, quantities)Active Cart Storage: 200M × 2 KB = 400 GB Cart History (1 year): 2 billion cartsTotal Cart Storage: 2B × 2 KB = 4 TB === ORDER STORAGE === Orders per Year: 18.75M × 365 = 6.84 billionAverage Order Record Size: 10 KB (items, addresses, payment refs)Annual Order Storage: 6.84B × 10 KB = 68.4 TBOrder History (5 years): 342 TB === INVENTORY DATA === Inventory Records: 350M products × 10 regional warehouses = 3.5BRecord Size: 100 bytes (product ID, warehouse, quantity, reserved)Total Inventory Data: 3.5B × 100 bytes = 350 GB (small but HOT)Notice that inventory data is relatively small (350 GB) but represents the hottest data in the system—every cart operation, every checkout, every page view showing availability must read and potentially update this data. This is a classic scenario where data size doesn't correlate with access complexity.
Every large-scale system operates under constraints that shape its architecture. Understanding these constraints helps us make informed trade-offs rather than chasing impossible ideals.
The CAP Theorem in E-Commerce Context:
For a global e-commerce platform, we must choose carefully:
Catalog Service: AP (Available + Partition Tolerant). During network partitions, we prefer showing potentially stale catalog data rather than failing requests. A customer seeing a slightly outdated price is better than seeing an error page.
Inventory Service: CP (Consistent + Partition Tolerant) for checkout operations. We cannot risk overselling. During partitions, we may reject checkout operations rather than risk selling items we don't have.
Order Service: CP with strong durability. Orders must never be lost or duplicated. We use synchronous replication and accept higher latency to guarantee consistency.
Cart Service: AP with session consistency. We prefer cart availability over cross-device instant sync. Users can tolerate a few seconds of delay in cart syncing across devices.
Defining clear API contracts early helps align teams and clarifies system boundaries. Here are the critical API operations for our three core subsystems:
1234567891011121314151617181920212223242526272829303132333435363738
// Product Catalog Service API interface ProductCatalogAPI { // Product retrieval getProduct(productId: string): Promise<Product>; getProductVariants(productId: string): Promise<ProductVariant[]>; // Search and discovery searchProducts(query: SearchQuery): Promise<SearchResults>; getCategory(categoryId: string): Promise<Category>; getCategoryProducts(categoryId: string, pagination: Pagination): Promise<ProductList>; // Pricing (real-time, may include dynamic pricing) getPrice(productId: string, variantId?: string, userId?: string): Promise<Price>; // Availability (delegates to inventory service internally) getAvailability(productId: string, variantId: string, location: Location): Promise<Availability>;} interface SearchQuery { query: string; filters: Filter[]; // Brand, price range, ratings, etc. sortBy: SortOption; // Relevance, price, rating, newest pagination: Pagination; userId?: string; // For personalized ranking} interface SearchResults { products: ProductSummary[]; facets: Facet[]; // Available filter options with counts totalCount: number; pagination: PaginationResult; searchMetadata: { queryInterpretation: string; spellCorrection?: string; suggestedQueries: string[]; };}12345678910111213141516171819202122232425262728293031323334353637383940414243444546
// Shopping Cart Service API interface CartAPI { // Cart operations getCart(sessionId: string, userId?: string): Promise<Cart>; addToCart(request: AddToCartRequest): Promise<CartUpdateResult>; updateQuantity(request: UpdateQuantityRequest): Promise<CartUpdateResult>; removeFromCart(request: RemoveFromCartRequest): Promise<CartUpdateResult>; // Session management mergeGuestCart(guestSessionId: string, userId: string): Promise<Cart>; // Saved items saveForLater(cartItemId: string): Promise<void>; moveToCart(savedItemId: string): Promise<CartUpdateResult>; // Validation validateCart(sessionId: string): Promise<CartValidationResult>;} interface AddToCartRequest { sessionId: string; userId?: string; productId: string; variantId: string; quantity: number; metadata?: Record<string, string>; // Gift wrapping, customization} interface CartUpdateResult { cart: Cart; success: boolean; warnings: CartWarning[]; // Low stock, price changed, etc. errors: CartError[]; // Out of stock, invalid variant, etc.} interface Cart { id: string; items: CartItem[]; subtotal: Money; estimatedShipping: Money; estimatedTax: Money; total: Money; appliedPromotions: Promotion[]; lastUpdated: Timestamp;}1234567891011121314151617181920212223242526272829303132333435363738394041424344454647
// Checkout Service API interface CheckoutAPI { // Checkout flow initiateCheckout(cartId: string): Promise<CheckoutSession>; setShippingAddress(sessionId: string, address: Address): Promise<CheckoutSession>; setShippingOption(sessionId: string, optionId: string): Promise<CheckoutSession>; applyPromoCode(sessionId: string, code: string): Promise<PromoCodeResult>; // Payment setPaymentMethod(sessionId: string, paymentMethod: PaymentMethod): Promise<CheckoutSession>; submitOrder(sessionId: string): Promise<OrderResult>; // Order retrieval getOrder(orderId: string, userId: string): Promise<Order>; getOrderHistory(userId: string, pagination: Pagination): Promise<OrderList>;} interface CheckoutSession { id: string; cart: Cart; shippingAddress?: Address; billingAddress?: Address; shippingOptions: ShippingOption[]; selectedShipping?: ShippingOption; paymentMethod?: PaymentMethodSummary; // Calculated totals subtotal: Money; shippingCost: Money; tax: Money; discount: Money; total: Money; // Validation state readyForPayment: boolean; validationErrors: ValidationError[]; expiresAt: Timestamp;} interface OrderResult { success: boolean; orderId?: string; confirmationNumber?: string; estimatedDelivery?: DateRange; error?: PaymentError | InventoryError;}We've established a comprehensive requirements foundation for building an Amazon-scale e-commerce platform. Let's consolidate the key takeaways:
What's Next:
With requirements clearly defined, we'll dive into the first major subsystem: the Product Catalog. You'll learn how to design a system that can store, search, and serve 350+ million products with sub-200ms latency, support complex filtering and full-text search, and handle continuous updates from millions of sellers.
You now have a Principal Engineer's perspective on e-commerce system requirements. These requirements will guide every architectural decision in the pages ahead—from database selection to caching strategies to consistency models. Every trade-off we make will trace back to satisfying these requirements.