Design Amazon

Design Amazon

Amazon is an e-commerce platform that allows users to browse and purchase products from a vast catalog, manage shopping carts, process payments, and track orders. It connects buyers with sellers and manages the entire transaction flow from product discovery to delivery.

Designing Amazon presents unique challenges including handling billions of products, maintaining inventory consistency, preventing overselling, managing distributed transactions, processing high-frequency updates, and ensuring sub-second response times during peak traffic events like Black Friday and flash sales.

Step 1: Understand the Problem and Establish Design Scope

Before diving into the design, it’s crucial to define the functional and non-functional requirements. For user-facing applications like this, functional requirements are the “Users should be able to…” statements, whereas non-functional requirements define system qualities via “The system should…” statements.

Functional Requirements

Core Requirements (Priority 1-3):

1. Users should be able to search for products with filters, sorting, and relevance ranking.
2. Users should be able to add products to a shopping cart that persists across devices.
3. Users should be able to proceed through checkout, make payments, and place orders.
4. The system should prevent overselling by maintaining accurate real-time inventory.

Below the Line (Out of Scope):

• Users should be able to write product reviews and ratings.
• Sellers should be able to list products and manage inventory.
• Users should be able to track order status and shipping.
• The system should provide personalized product recommendations.
• Users should be able to create wishlists and save items for later.
• The system should support flash sales and time-limited deals.

Non-Functional Requirements

Core Requirements:

• The system should prioritize low latency with search latency under 200ms (p99) and cart updates under 100ms.
• The system should ensure strong consistency for inventory, payments, and orders to prevent overselling and double charging.
• The system should be able to handle high throughput, especially during peak hours or special events (100K orders/second during flash sales, 5M search queries/second).

Below the Line (Out of Scope):

• The system should ensure the security and privacy of user data, complying with PCI DSS for payments.
• The system should be resilient to failures, with 99.99% uptime for checkout flow.
• The system should have robust monitoring, logging, and alerting to quickly identify and resolve issues.
• The system should facilitate easy updates and maintenance without significant downtime.

Clarification Questions & Assumptions:

• Platform: Web and mobile apps for users, separate seller portal.
• Scale: 300 million daily active users with 50 million concurrent users during peak events.
• Catalog Size: 10 billion products with hierarchical categories.
• Geographic Coverage: Global, with multiple fulfillment centers.
• Payment: Integration with third-party payment processors (Stripe, PayPal).

Step 2: Propose High-Level Design and Get Buy-in

Planning the Approach

Before moving on to designing the system, it’s important to plan your strategy. For user-facing product-style questions, the plan should be straightforward: build your design up sequentially, going one by one through your functional requirements. This will help you stay focused and ensure you don’t get lost in the weeds.

Defining the Core Entities

To satisfy our key functional requirements, we’ll need the following entities:

User: Any person who uses the platform to browse and purchase products. Includes personal information such as name, contact details, shipping addresses, and preferred payment methods for transactions.

Product: Any item available for purchase on the platform. Contains details such as title, description, category, brand, price, images, seller information, and specifications. Each product has associated inventory tracking.

Cart: A collection of products that a user intends to purchase. Includes items with quantities, prices at the time of addition, and total amount. Carts persist across sessions and devices for logged-in users.

Order: A completed transaction from the moment a user confirms checkout until delivery. Records all pertinent details including the user identity, items purchased, quantities, prices, payment information, shipping address, order status, and timestamps for key events.

Inventory: Real-time availability information for products. Tracks available quantity, reserved quantity for pending checkouts, warehouse location, and version numbers for optimistic locking to prevent race conditions.

API Design

Product Search Endpoint: Used by users to search for products with various filters and sorting options.

GET /products/search -> ProductList
Query Params: {
  q: string,
  category: string,
  minPrice: number,
  maxPrice: number,
  sort: string
}

Add to Cart Endpoint: Used by users to add products to their shopping cart.

POST /cart/items -> Cart
Body: {
  productId: string,
  quantity: number
}

Get Cart Endpoint: Used to retrieve the current cart contents for a user.

GET /cart -> Cart

Checkout Initiation Endpoint: Used by users to begin the checkout process, which reserves inventory.

POST /checkout/initiate -> CheckoutSession
Body: {
  cartId: string
}

Process Payment Endpoint: Used to process payment and create the final order.

POST /checkout/payment -> Order
Body: {
  checkoutSessionId: string,
  paymentMethodId: string,
  shippingAddressId: string
}

Note: The userId is present in the session cookie or JWT and not in the body or path params. Always consider security implications - never trust data sent from the client as it can be easily manipulated.

High-Level Architecture

Let’s build up the system sequentially, addressing each functional requirement:

1. Users should be able to search for products with filters, sorting, and relevance ranking

The core components necessary to fulfill product search are:

• User Client: The primary touchpoint for users, available on web, iOS, and Android. Interfaces with the system’s backend services.
• API Gateway: Acts as the entry point for client requests, routing requests to appropriate microservices. Also manages cross-cutting concerns such as authentication, rate limiting, and SSL termination.
• Search Service: Manages product search functionality using Elasticsearch. Handles full-text search, filters, facets, sorting, and relevance ranking with machine learning models.
• Product Service: Manages the product catalog including CRUD operations, category management, and product metadata. Stores data in PostgreSQL sharded by product ID.
• Cache Layer: Uses Redis to cache frequently accessed product details and search results with appropriate TTLs to reduce database load.

Product Search Flow:

1. The user enters a search query into the client app, which sends a GET request to /products/search with query parameters.
2. The API gateway receives the request and handles authentication and rate limiting before forwarding to the Search Service.
3. The Search Service first checks Redis cache for frequent queries. If not found, it queries Elasticsearch with the search terms and filters.
4. Elasticsearch performs full-text search across product titles, descriptions, and tags, applying filters for category, price range, and availability.
5. Results are ranked using a combination of text relevance (BM25 algorithm), popularity scores, user personalization factors, and business rules.
6. The Search Service caches the results in Redis with a 5-minute TTL and returns the product list to the client.

2. Users should be able to add products to a shopping cart that persists across devices

We extend our existing design to support cart management:

• Cart Service: Manages shopping cart operations including add, remove, update, and cross-device synchronization. Uses Redis for fast access and PostgreSQL for durability.
• Inventory Service: Checks product availability before allowing items to be added to cart.

Add to Cart Flow:

1. The user clicks “Add to Cart” in the client app, sending a POST request with the productId and quantity.
2. The API gateway performs authentication and forwards to the Cart Service.
3. The Cart Service first calls the Inventory Service to verify that the requested quantity is available.
4. If available, for logged-in users, the Cart Service updates both Redis (for fast access) and PostgreSQL (for persistence).
5. For anonymous users, the cart is stored only in Redis with a 24-hour TTL, identified by session ID.
6. The service publishes a “cart.item_added” event to Kafka for analytics and recommendation systems.
7. The updated cart is returned to the client.

Cart Synchronization: When a user logs in after browsing anonymously, the system merges the anonymous session cart with the user’s persistent cart. Items that exist in both carts have their quantities combined, and the session cart is then deleted.

3. Users should be able to proceed through checkout, make payments, and place orders

We need to introduce new components to facilitate the checkout flow:

• Checkout Service: Orchestrates the multi-step checkout process including address validation, shipping calculation, tax calculation, and order creation.
• Payment Service: Integrates with third-party payment gateways (Stripe, PayPal) to process payments with PCI DSS compliance, idempotency, and retry logic.
• Order Service: Manages order creation, status tracking, and order history. Uses PostgreSQL sharded by user ID and implements event sourcing for complete audit trails.
• Notification Service: Sends order confirmation emails and push notifications to users.

Checkout Flow:

1. The user clicks “Proceed to Checkout”, which sends a POST request to /checkout/initiate.
2. The Checkout Service creates a checkout session and calls the Inventory Service to reserve items from the cart.
3. The Inventory Service uses distributed locks (Redis) to atomically reserve inventory, preventing overselling.
4. The user completes the checkout steps: confirms shipping address, selects payment method, and reviews the order.
5. When the user clicks “Place Order”, a POST request is sent to /checkout/payment.
6. The Payment Service processes the payment using an idempotency key (checkout session ID plus timestamp) to prevent double charging.
7. If payment succeeds, the Order Service creates an order record and confirms the inventory reservation.
8. The Cart Service clears the user’s cart.
9. The Notification Service sends an order confirmation email.
10. The order details are returned to the client.

4. The system should prevent overselling by maintaining accurate real-time inventory

To ensure inventory consistency, we need robust mechanisms:

• Distributed Locking: Redis-based locks ensure that only one checkout process can reserve specific inventory at a time.
• Reservation System: Inventory is reserved during checkout with a 10-minute expiration. If checkout isn’t completed, the reservation is automatically released.
• Optimistic Locking: Database records include version numbers to detect and handle concurrent modifications.

Inventory Consistency Flow:

1. When checkout is initiated, the system attempts to acquire a distributed lock for each product using Redis SET with NX (only if not exists) and EX (expiration) flags.
2. If the lock is acquired, the system checks current inventory availability in PostgreSQL using SELECT FOR UPDATE to lock the row.
3. The system verifies that available quantity is sufficient using optimistic locking by checking the version number.
4. If sufficient, it updates the inventory: decrements available quantity, increments reserved quantity, and increments the version number.
5. A reservation record is created with a 10-minute expiration time.
6. If payment succeeds, the reservation is confirmed and linked to the order.
7. If checkout times out or fails, a background cleanup job releases expired reservations by returning inventory to available quantity.

Step 3: Design Deep Dive

With the core functional requirements met, it’s time to dig into the non-functional requirements via deep dives. These are the critical areas that separate good designs from great ones.

Deep Dive 1: How do we efficiently index and search billions of products with low latency?

Searching through 10 billion products in a traditional relational database would be extremely slow. Full-text search requires specialized indexing and query optimization.

Solution: Elasticsearch for Product Search

Elasticsearch is a distributed search engine built on Apache Lucene, designed for fast full-text search and analytics. It provides several advantages:

• Inverted Index: Elasticsearch builds inverted indexes where each unique word maps to the documents containing it, enabling fast full-text search.
• Distributed Sharding: The product catalog is distributed across multiple shards for parallel query execution.
• Relevance Scoring: Built-in BM25 algorithm for text relevance combined with custom scoring factors.

Index Structure: Each product document in Elasticsearch contains fields like product ID, title, description, category, brand, price, rating, review count, stock status, seller information, attributes (color, size, etc.), and metadata. The index is configured with appropriate analyzers for text fields to handle stemming, synonyms, and language-specific processing.

Search Query Processing: When a search request arrives, Elasticsearch constructs a boolean query with must clauses for the search terms (using multi-match across title, description, and tags with field boosting) and filter clauses for category, price range, stock availability, and attribute values. The query uses fuzzy matching to handle typos and returns aggregations (facets) for filters like brand and price ranges.

Relevance Ranking: Results are ranked by combining multiple factors: text matching score from BM25, product popularity based on click-through rate, user personalization from past purchases and browsing history, business rules for promoted products and margins, and recency boosting for newer products.

Optimizations: To handle the scale, Elasticsearch uses several optimizations: sharding by category for hot categories, routing keys to query specific shards, caching frequent queries in Redis with 5-minute TTL, pre-computing aggregations for common filters, and index aliases for zero-downtime reindexing.

Index Update Strategy: Product data changes are streamed through Kafka to Logstash which feeds Elasticsearch. Real-time indexing handles new products, bulk indexing processes batches of 1000 products, partial updates handle price and inventory changes, and full reindexing occurs weekly using aliases to avoid downtime.

Deep Dive 2: How do we manage shopping carts for both anonymous and logged-in users with cross-device sync?

Cart management needs to handle different user states and ensure data persistence without creating a poor user experience.

Solution: Dual Storage Strategy

We use a two-tier approach combining Redis and PostgreSQL:

Session Cart (Anonymous Users): For users who aren’t logged in, carts are stored in Redis with a key structure like “cart:session:{sessionId}”. The value contains an array of items (each with product ID, quantity, price, and added timestamp), total amount, and last updated timestamp. A 24-hour TTL automatically cleans up abandoned carts.

Persistent Cart (Logged-in Users): For authenticated users, carts are stored in PostgreSQL with two tables: a carts table containing cart ID, user ID, and timestamps, and a cart_items table containing cart item ID, cart ID, product ID, quantity, price, and added timestamp. This provides durability across sessions.

Dual Write Pattern: For logged-in users, the Cart Service performs dual writes: it updates PostgreSQL for durability and writes to Redis for fast reads. The Redis cache uses user ID as the key and has no expiration since it’s backed by the database.

Cart Merging on Login: When an anonymous user logs in, the system retrieves the session cart from Redis and the persistent cart from PostgreSQL. It merges the carts by combining quantities for duplicate products, saves the merged result to PostgreSQL, updates the Redis cache, and deletes the session cart. This ensures a seamless transition without losing items.

Cart Synchronization Across Devices: For logged-in users with multiple active devices, the system uses the user ID as the source of truth. All reads come from Redis for speed with PostgreSQL as the durable backup. For real-time updates when a user is active on multiple devices, WebSocket connections push cart changes to all connected clients.

Abandoned Cart Handling: Background jobs scan for carts older than 24 hours and trigger email reminders through the notification service. The system tracks conversion rates to optimize reminder timing and cleans up carts older than 90 days to manage storage costs.

Deep Dive 3: How do we ensure inventory consistency and prevent overselling with high concurrency?

The challenge is preventing overselling when multiple users try to purchase the last few items simultaneously. Without proper coordination, race conditions can allow more orders than available inventory.

Solution: Multi-Layer Consistency Strategy

We combine several techniques to ensure strong consistency:

Database Schema Design: The inventory table includes product ID, warehouse ID, available quantity (with a check constraint ensuring it’s non-negative), reserved quantity, and a version column for optimistic locking. A separate inventory_reservations table tracks each reservation with reservation ID, product ID, user ID, order ID, quantity, status (RESERVED, CONFIRMED, RELEASED), expiration timestamp, and creation timestamp.

Distributed Locks with Redis: Before modifying inventory, the system acquires a distributed lock using Redis SET command with NX (only set if not exists) and EX (expiration time) flags. The lock key is “inventory:lock:{productId}” and the value is a unique identifier (UUID). The lock has a 5-second timeout to prevent deadlocks. A Lua script ensures atomic lock release by verifying ownership before deletion.

Optimistic Locking: After acquiring the distributed lock, the system reads the current inventory record including the version number. When updating, it uses a WHERE clause that checks the version hasn’t changed: “WHERE product_id = X AND version = Y AND available_quantity >= Z”. If no rows are affected, a concurrent modification occurred and the operation retries.

Reservation Flow: When checkout begins, the system acquires a distributed lock for each product, queries current inventory with SELECT FOR UPDATE to lock the row, verifies sufficient availability, updates inventory by decrementing available quantity and incrementing reserved quantity while incrementing the version, creates a reservation record with 10-minute expiration, schedules an expiration job, and returns the reservation ID.

Cleanup Process: A background job runs every minute to find expired reservations. For each expired reservation, it returns the quantity to available inventory, updates the reserved quantity, increments the version, and marks the reservation as RELEASED. This ensures temporary failures don’t permanently lock inventory.

Lock Implementation Details: The Redis lock implementation uses a context manager pattern. When acquiring, it retries up to 10 times with 50ms exponential backoff. Each attempt uses SET with NX and EX flags for atomicity. On release, a Lua script checks that the lock is still owned by the same identifier before deletion, preventing accidental release of another process’s lock.

Deep Dive 4: How do we handle payment processing with idempotency to prevent double charging?

Payment processing must be idempotent because network failures, timeouts, or retries could cause duplicate payment attempts. Charging a customer twice is a critical failure.

Solution: Idempotency Keys and State Machine

We implement comprehensive idempotency handling:

Idempotency Key Design: Each payment attempt uses a unique idempotency key combining the order ID (or checkout session ID) and attempt number. This key is stored in the database and sent to the payment gateway (Stripe also supports idempotency keys natively).

Payment State Machine: Payments progress through states: PROCESSING (initial state when payment is attempted), COMPLETED (payment succeeded and order confirmed), FAILED (payment declined or error occurred), and REFUNDED (payment reversed due to cancellation or fraud).

Payment Processing Flow: When a payment request arrives, the system first checks if a payment with the same idempotency key already exists. If it exists and is COMPLETED, it returns the existing payment ID (duplicate request). If PROCESSING, it raises an exception indicating payment is in progress. If FAILED, it allows retry with a new attempt.

If no existing payment is found, the system creates a payment record with PROCESSING status. It then calls the payment gateway (Stripe) with the idempotency key. The gateway processes the charge and returns a result. If successful, the payment status is updated to COMPLETED with the gateway transaction ID and timestamp. A “payment.completed” event is published to Kafka. If failed, the status is updated to FAILED with the error message, and a “payment.failed” event is published.

Retry Logic: For transient failures (network errors, gateway timeouts), the system implements exponential backoff retry. The first retry is after 1 second, second after 2 seconds, third after 4 seconds. Each retry uses a new attempt number in the idempotency key. After 3 retries, the payment is marked as failed and the user is notified.

Consistency with Order Creation: The payment and order creation are part of a distributed transaction using the Saga pattern. If payment succeeds but order creation fails, a compensating transaction refunds the payment. If inventory confirmation fails after payment, the payment is also refunded.

Deep Dive 5: How do we coordinate the multi-step checkout process as a distributed transaction?

Checkout involves multiple services (Inventory, Payment, Order, Cart) that must be coordinated. Partial failures must be handled gracefully with proper rollback.

Solution: Saga Pattern for Distributed Transactions

Traditional ACID transactions don’t work across microservices. The Saga pattern coordinates distributed transactions as a sequence of local transactions with compensating actions.

Order Placement Saga Steps: The saga consists of: Reserve Inventory (acquire locks and create reservations), Process Payment (charge payment method), Create Order (record order in database), Confirm Inventory Reservations (mark reservations as confirmed), Clear Cart (remove items from user’s cart), and Send Notifications (email and push notifications).

Saga State Tracking: The system maintains saga state including saga ID, user ID, cart ID, list of completed steps, and compensation actions needed. This state is persisted to survive service restarts.

Saga Execution: The Checkout Service acts as the saga coordinator. It executes each step sequentially. After each successful step, it updates the saga state and proceeds to the next step. If any step fails, it triggers compensating actions for all previously completed steps in reverse order.

Compensation Actions: If inventory reservation fails, no compensation is needed (no resources allocated). If payment fails, inventory is released through the compensation action. If order creation fails, both payment is refunded and inventory is released. If notification fails, the order is still valid (notifications are non-critical and can be retried asynchronously).

Saga Implementation Patterns: Two common patterns are choreography (each service publishes events that trigger the next step) and orchestration (a central coordinator directs the saga). For checkout, orchestration is preferred because it provides better visibility and error handling. The coordinator can be implemented using workflow engines like Temporal, AWS Step Functions, or Uber’s Cadence.

Event Sourcing for Orders: The Order Service uses event sourcing to maintain a complete audit trail. Every state change (ORDER_CREATED, PAYMENT_CONFIRMED, ORDER_SHIPPED, ORDER_DELIVERED, ORDER_CANCELLED, ORDER_REFUNDED) is stored as an event. The current order state is reconstructed by replaying events. Events are published to Kafka for downstream consumers like analytics and fulfillment services.

Handling Service Failures: If the Checkout Service crashes mid-saga, the workflow engine resumes from the last checkpoint using the persisted saga state. Timeouts are configured for each step to prevent indefinite waiting. If a step times out, the saga moves to compensation.

Deep Dive 6: How do we handle flash sales with extreme concurrency (100K+ simultaneous requests)?

Flash sales present a unique challenge: thousands of users simultaneously trying to purchase limited inventory (e.g., 1000 items) causing extreme load spikes.

Solution: Multiple Defensive Layers

Rate Limiting: The first line of defense is aggressive rate limiting. Each user is limited to 5 purchase attempts per minute using Redis counters. The key structure is “flash_sale:{saleId}:user:{userId}” with a 60-second TTL. This prevents a single user from overwhelming the system.

Redis-Based Inventory Counter: Instead of hitting the database for every request, flash sale inventory is pre-loaded into Redis. The key “flash_sale:{saleId}:inventory” stores the remaining quantity. The Redis DECR command atomically decrements the counter. If the result is negative, the item is sold out and the counter is incremented back (rollback). This provides O(1) inventory checks with atomic operations.

Temporary Reservations: When a user successfully decrements the counter, they receive a temporary reservation valid for 2 minutes. The reservation key “flash_sale:{saleId}:reservation:{userId}” is stored in Redis with a 120-second TTL. The user must complete checkout within this window or the reservation expires.

Asynchronous Order Processing: Flash sale orders are enqueued to a message queue (Kafka or RabbitMQ) for asynchronous processing. This decouples the initial inventory reservation from the full checkout flow, allowing the API to respond quickly. Worker processes consume from the queue and complete order processing.

Pre-warming Strategy: One hour before the flash sale starts, the system pre-warms by loading sale information into Redis with 2-hour TTL, populating the inventory counter, warming product cache in Redis, pre-computing price and shipping information, and scaling up service instances horizontally.

Queue Management: During extreme load, implement virtual queues where users are placed in a waiting room and allowed to proceed in batches. This prevents thundering herd problems and provides a better user experience than failure. The queue position is stored in Redis sorted sets with score as timestamp.

Cleanup and Reconciliation: After the flash sale, reconcile Redis inventory with database inventory to ensure consistency. Process any pending reservations that didn’t complete. Generate analytics on conversion rates and system performance. Scale down infrastructure to normal levels.

Deep Dive 7: How do we build a recommendation system for product discovery?

Recommendations significantly increase conversion rates by showing users products they’re likely to purchase.

Solution: Hybrid Recommendation Architecture

Collaborative Filtering (Offline): The system runs daily batch jobs to train collaborative filtering models using user-item interaction data. Interactions include purchases (weight 5), add to cart (weight 3), and views (weight 1) from the last 90 days. The data is structured as a sparse matrix with users as rows and products as columns.

The Alternating Least Squares (ALS) algorithm trains on this matrix to learn latent factors for users and products. The model is configured with 100 factors, 0.01 regularization, and 15 iterations. After training, recommendations are pre-computed for the top 1 million active users (those active in the last 30 days) and cached in Redis with 24-hour TTL.

Content-Based Filtering: Products are represented as embedding vectors in high-dimensional space based on attributes like category, brand, description text, and specifications. Similar products are found using cosine similarity in this embedding space. A vector database (like Pinecone or Weaviate) enables fast nearest neighbor search. This is particularly useful for new products that lack interaction data (cold start problem).

Real-Time Personalization: When generating recommendations for a user, the system merges signals from multiple sources: pre-computed collaborative filtering recommendations from Redis, content-based recommendations from recently viewed products, session context (products viewed in the last 30 minutes), trending products in the user’s preferred categories, and high-margin products (business rules).

These recommendations are re-ranked based on real-time context including time of day, user’s device type, current location, and browsing speed. A/B testing framework continually evaluates different ranking strategies and model versions.

Feature Engineering: Important features include user demographics, purchase history, browsing behavior, time since last purchase, cart abandonment patterns, price sensitivity (derived from past purchases), category preferences, and seasonal signals.

Model Serving: Trained models are deployed on GPU clusters for low-latency inference. Models are versioned and deployed using blue-green deployment to enable rollback. Feature vectors are pre-computed and cached to minimize serving latency (target: under 50ms).

Cold Start Handling: For new users without history, the system falls back to: trending products globally, popular products in the user’s inferred category interest (based on first search or view), and products with high ratings and reviews. As the user interacts with the platform, the system quickly transitions to personalized recommendations.

Deep Dive 8: How do we detect and prevent fraud in real-time?

E-commerce platforms are targets for various fraud types including stolen credit cards, account takeover, friendly fraud (chargebacks), and coordinated bot attacks.

Solution: Multi-Layer Fraud Detection

Rule-Based Checks (Fast Path): The first layer applies deterministic rules that can quickly flag obvious fraud: shipping address doesn’t match billing address on first order (score 0.3), high-value order from new account (score 0.4), multiple failed payment attempts (score 0.5), suspicious email domain from blacklist (score 0.6), and VPN or proxy usage detected (score 0.2). Scores are additive up to 1.0.

Feature Extraction: For each order, the system extracts features including order value, account age in days, whether it’s the first order, address mismatch boolean, email domain, count of failed payment attempts in last 24 hours, IP address analysis (VPN detection, geolocation), device fingerprint, time since last order, and typing speed patterns.

Machine Learning Model: A gradient boosting model (XGBoost or LightGBM) is trained on historical fraud data. Features include user behavior patterns, transaction characteristics, device information, and network signals. The model outputs a fraud probability score between 0 and 1.

Score Combination: The final fraud score combines rule-based score (weight 0.4) and ML model score (weight 0.6). This hybrid approach leverages both explicit rules for known patterns and ML for detecting subtle anomalies.

Action Workflow: Based on the final score, different actions are taken: score below 0.3 means auto-approve and process order normally, score 0.3 to 0.7 means route to manual review queue for human verification, score above 0.7 means auto-decline and flag account for investigation.

Feedback Loop: Human review decisions and actual fraud outcomes (chargebacks) feed back into the training data. The model is retrained weekly with new data. Feature importance analysis identifies which signals are most predictive. A/B tests evaluate model versions to prevent regression.

Behavioral Signals: Advanced fraud detection considers behavioral patterns: typing speed and rhythm (bots type differently), mouse movement patterns (bots move in straight lines), time spent on each page (fraud attempts are often rushed), navigation sequence (unusual paths through the site), and session fingerprinting (device and browser characteristics).

Network Analysis: The system tracks relationships between entities: multiple accounts from the same device, multiple payment methods used by one account, multiple accounts shipping to the same address, and coordinated burst of orders (potential bot attack). Graph analysis identifies fraud rings.

Step 4: Wrap Up

In this chapter, we proposed a system design for an e-commerce platform like Amazon. If there is extra time at the end of the interview, here are additional points to discuss:

Additional Features:

• Product reviews and ratings with verified purchase badges.
• Seller management portal for listing products and managing inventory.
• Advanced recommendation algorithms using deep learning and transformer models.
• Order tracking integration with shipping carriers.
• Wishlist and save-for-later functionality with price drop alerts.
• Gift cards and promotional codes with complex business rules.
• Subscribe and save for recurring purchases.

Scaling Considerations:

• Horizontal Scaling: All services should be stateless to allow horizontal scaling with load balancers distributing traffic.
• Database Sharding: Products sharded by product ID hash, users and orders sharded by user ID, inventory sharded by warehouse ID and product ID.
• Caching Layers: Multi-level caching with CDN for static assets and images, Redis for hot data (product details, cart, inventory), and Elasticsearch for search results.
• Message Queue Scaling: Use partitioned topics in Kafka for parallel processing with consumer groups.

Error Handling:

• Network Failures: Implement retry logic with exponential backoff and circuit breakers.
• Service Failures: Use circuit breakers to prevent cascading failures and fallback to cached data when available.
• Database Failures: Automatic failover to replica databases with health checks.
• Payment Gateway Failures: Retry with exponential backoff, fall back to alternative payment processors if available.

Security Considerations:

• Encrypt sensitive data in transit using TLS and at rest using AES-256.
• Implement proper authentication using JWT tokens with short expiration and refresh tokens.
• Payment data must never be stored directly; use tokenization from payment processors (PCI DSS compliance).
• Rate limiting to prevent abuse and DDoS attacks using Redis counters and token buckets.
• Input validation and sanitization to prevent injection attacks (SQL injection, XSS).
• Regular security audits and penetration testing.

Monitoring and Analytics:

• Track key metrics: request rate, latency percentiles (p50, p95, p99), error rates (4xx, 5xx), database connection pool usage, cache hit ratio, search query latency, inventory reservation success rate, payment success rate, and fraud detection accuracy.
• Distributed tracing using tools like Jaeger or Zipkin to identify bottlenecks across microservices.
• Real-time dashboards for operations team with critical alerts routed to PagerDuty.
• Business metrics: conversion rate, average order value, cart abandonment rate, search-to-purchase rate.

Database Optimization:

• Read replicas for scaling read operations without impacting write performance.
• Connection pooling using PgBouncer to manage database connections efficiently.
• Prepared statements and parameterized queries to prevent SQL injection and improve performance.
• Index optimization on frequently queried columns (user ID, product ID, order status).
• Partitioning large tables by date or ID ranges to improve query performance.

Consistency vs Availability Trade-offs: Following the CAP theorem, the system makes deliberate choices: strong consistency for inventory, payments, and orders (critical operations where inconsistency causes business loss), eventual consistency for recommendations, product reviews, and analytics (acceptable to be slightly stale), and availability favored over consistency for product search and browsing (stale cache is acceptable).

Global Expansion:

• Multi-region deployment with data replicated across regions for disaster recovery.
• Geographic load balancing to route users to nearest data center for lower latency.
• Database sharding by geographic region for data locality.
• CDN with edge locations worldwide for static content delivery.
• Handle currency conversion and internationalization.

Cost Optimization:

• Auto-scaling infrastructure based on traffic patterns to reduce costs during off-peak hours.
• Use spot instances for batch processing jobs like recommendation model training.
• Optimize data retention policies: archive old orders to cheaper storage, delete expired carts, compress logs before archival.
• CDN cost optimization by serving popular content from CDN and less popular directly.

Future Improvements:

• Machine learning for demand forecasting to optimize inventory allocation across warehouses.
• Dynamic pricing algorithms based on demand, competition, and inventory levels.
• Voice search and image search capabilities using natural language processing and computer vision.
• Augmented reality for virtual product try-on (furniture placement, clothing fitting).
• Blockchain for supply chain transparency and counterfeit prevention.

Congratulations on getting this far! Designing Amazon is a complex system design challenge that encompasses search and discovery, distributed transactions, strong consistency guarantees, high-throughput processing, and sophisticated recommendation systems. The key is to start with core functional requirements, layer in strong consistency where needed, optimize for performance at scale, and handle edge cases gracefully.

---

Summary

This comprehensive guide covered the design of an e-commerce platform like Amazon, including:

1. Core Functionality: Product search with Elasticsearch, cart management with dual storage, checkout orchestration with the Saga pattern, and inventory consistency with distributed locking.
2. Key Challenges: Handling billions of products, maintaining inventory consistency under high concurrency, preventing double charging, coordinating distributed transactions, and scaling for flash sales.
3. Solutions: Elasticsearch for search with relevance ranking, Redis and PostgreSQL for cart persistence, distributed locks with optimistic locking for inventory, idempotency keys for payments, Saga pattern for distributed transactions, and pre-warming for flash sales.
4. Scalability: Horizontal scaling with sharding, multi-level caching (CDN, Redis, database), event-driven architecture with Kafka, and asynchronous processing with message queues.

The design demonstrates how to handle e-commerce systems with massive scale, strong consistency requirements for critical operations, eventual consistency for non-critical features, and complex workflows involving multiple microservices working together to provide a seamless shopping experience.