E-Commerce Platform Architecture: Designing for Scale

Building an e-commerce platform that handles millions of products, concurrent shoppers, and flash-sale traffic spikes requires thoughtful e-commerce architecture. In this guide, we walk through every major subsystem — from product catalog to warehouse fulfillment — and explain the patterns that keep large-scale platforms reliable.

Functional Requirements#

• Users can browse and search a product catalog.
• Users can add items to a cart and proceed to checkout.
• The system processes orders end-to-end: payment, inventory reservation, and fulfillment.
• Personalized recommendations surface relevant products.
• Sellers can manage their inventory and listings.
• The platform supports flash sales with sudden traffic bursts.

Non-Functional Requirements#

• High availability — downtime directly costs revenue.
• Low latency — product pages load in under 200 ms.
• Eventual consistency — acceptable for catalog updates; strong consistency for payments and inventory.
• Horizontal scalability — handle 10× traffic during peak events.

Scale Estimation#

Assume 100 million products, 50 million daily active users, and 5 million orders per day.

• Browse QPS: ~100K product page views/sec at peak.
• Search QPS: ~30K queries/sec at peak.
• Order QPS: 5M / 86400 ≈ ~58 orders/sec average, peak ~500/sec during flash sales.
• Storage: Product data ~5 KB each → 500 GB. Order records grow ~15 GB/day.

High-Level Architecture#

The platform is decomposed into microservices:

1. Product Catalog Service — CRUD for products, categories, attributes.
2. Inventory Service — tracks stock levels across warehouses.
3. Cart Service — manages user shopping carts.
4. Order Service — orchestrates the checkout and order lifecycle.
5. Payment Service — handles charges, refunds, and payouts.
6. Search Service — full-text and faceted product search.
7. Recommendation Service — personalized product suggestions.
8. User Service — authentication, profiles, addresses.
9. Notification Service — email, SMS, push notifications.
10. Fulfillment Service — warehouse picking, packing, shipping.

An API Gateway handles routing, auth, rate limiting, and request aggregation (BFF pattern).

Product Catalog#

The catalog stores product metadata: title, description, images, price, attributes (size, color), and category taxonomy.

Storage#

Use a relational database (PostgreSQL) for structured product data and a document store (MongoDB or DynamoDB) for flexible attribute schemas — different product categories have wildly different attributes.

Caching#

Product pages are read-heavy. Use a multi-tier cache:

• CDN for static assets (images, CSS, JS).
• Application cache (Redis) for product detail JSON — TTL of a few minutes.
• Database query cache for frequent catalog queries.

Invalidate caches on product updates via an event-driven pipeline.

Inventory Management#

Inventory is critical — overselling destroys customer trust.

Stock Tracking#

Each SKU has a stock count per warehouse. The Inventory Service exposes two key operations:

• Reserve — decrement available stock when an order is placed.
• Release — increment stock if an order is cancelled or payment fails.

Use optimistic locking or atomic decrements (e.g., UPDATE inventory SET qty = qty - 1 WHERE sku = ? AND qty > 0) to prevent overselling under concurrency.

Warehouse Distribution#

For multi-warehouse setups, route reservation requests to the warehouse closest to the shipping address, falling back to others if stock is unavailable.

Cart Service#

Carts must persist across sessions and devices.

• Logged-in users: Store carts in Redis with the user ID as key. Back up to a database for durability.
• Guest users: Store carts in local storage or a session-keyed Redis entry. Merge with the user's cart upon login.

Cart entries include SKU, quantity, selected attributes, and a snapshot of the price at the time of addition (recalculated at checkout).

Checkout Flow#

Checkout is a multi-step process:

1. Validate cart — confirm all items are still in stock and prices are current.
2. Calculate totals — subtotal, tax, shipping, discounts/coupons.
3. Reserve inventory — temporarily hold stock for the user (TTL ~10 minutes).
4. Collect payment — authorize or charge via the payment gateway.
5. Create order — persist the order record with status CONFIRMED.
6. Trigger fulfillment — send the order to the warehouse system.

If any step fails, previous steps must be compensated (e.g., release inventory if payment fails).

Order Processing with the Saga Pattern#

In a microservices architecture, a single order touches multiple services (inventory, payment, fulfillment). A distributed transaction across all of them is impractical.

The saga pattern breaks the order into a sequence of local transactions, each with a compensating action:

Orchestration vs. Choreography#

• Orchestration: A central Order Saga Coordinator calls each service in sequence. Easier to reason about and debug.
• Choreography: Each service listens to events and acts independently. More decoupled but harder to trace.

For e-commerce, orchestration is often preferred because the checkout flow is well-defined and debugging failed orders is critical.

Payment Integration#

The Payment Service integrates with gateways like Stripe or Adyen.

• Authorization at checkout — verify the card and hold funds.
• Capture at shipment — actually charge when the order ships.
• Refunds — partial or full, triggered by returns or cancellations.

Implement idempotency keys on all payment API calls to safely retry on network failures. Store payment events in an append-only ledger for auditing.

Search and Recommendations#

Search#

Use Elasticsearch for full-text search with:

• Tokenization and stemming for relevant results.
• Faceted filtering — brand, price range, rating, category.
• Autocomplete with an edge-ngram analyzer.
• Relevance tuning — boost by sales velocity, rating, and margin.

Keep the search index in sync via a CDC (change data capture) pipeline from the catalog database.

Recommendations#

Recommendation approaches:

• Collaborative filtering — "customers who bought X also bought Y."
• Content-based filtering — similar product attributes.
• Real-time personalization — based on browsing session, use a feature store and a lightweight ML model.

Precompute recommendation lists offline (batch) and serve them from a cache. Supplement with real-time signals for the current session.

Personalization#

Beyond recommendations, personalization includes:

• Search ranking — boost products aligned with user preferences.
• Homepage curation — personalized banners and category highlights.
• Email campaigns — abandoned cart reminders, restock alerts.

A User Event Stream (Kafka) captures clicks, views, add-to-carts, and purchases. A real-time processing layer (Flink or Spark Streaming) updates user profiles that feed into personalization models.

Warehouse and Fulfillment#

Once an order is confirmed:

1. Routing — assign the order to the optimal fulfillment center based on proximity and stock.
2. Picking — generate a pick list for warehouse workers.
3. Packing — items are packed and a shipping label is generated via carrier APIs (UPS, FedEx).
4. Shipping — the package is handed off to the carrier. Tracking info is pushed to the customer.
5. Delivery — carrier delivers; status is updated via webhook.

The Fulfillment Service manages these states and integrates with warehouse management systems (WMS).

Scalability for Flash Sales#

Flash sales can spike traffic 10–50× in seconds. Strategies:

• Pre-scale infrastructure — spin up extra instances before the event.
• Queue-based checkout — during extreme load, place users in a virtual queue. Process checkout requests at a controlled rate.
• Inventory pre-warming — load flash-sale SKU inventory into Redis for atomic decrements without hitting the database.
• Rate limiting — prevent bots from hoarding stock.
• Static page caching — pre-render product detail pages and serve from CDN.
• Circuit breakers — isolate failing services so the rest of the platform stays healthy.

Data Storage Summary#

Summary#

A robust e-commerce architecture balances strong consistency where it matters (inventory, payments) with eventual consistency where speed is king (catalog, recommendations). The saga pattern keeps distributed order processing reliable without distributed transactions. And flash-sale readiness — through queuing, pre-scaling, and caching — ensures the platform holds up when traffic explodes.

---

Ready to master system design interviews? Try codelit.io — practice with AI-powered mock interviews covering e-commerce, ride sharing, and dozens more real-world architectures.

This is article #186 in our engineering blog series.