System Design/general/Design Simple E-commerce Website

Design Simple E-commerce Website

EASY15 minDatabaseAPI DesignLoad Balancing

Design an e-commerce platform like Amazon that allows users to search for products, add items to their shopping cart, and place orders for those items.

Design an e-commerce platform like Amazon that allows users to search for products, add items to their shopping cart, and place orders for those items. Use this guide to structure the discussion, test the design under pressure, and practise explaining trade-offs clearly.

Problem and Scope

Design an e-commerce platform like Amazon. Focus on the core functionalities that enable users to search for products, add items to a cart, and place orders.

Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

  • Users should be able to search for products based on queries/keywords
  • Users should be able to add items to their shopping cart
  • Multiple users from the same account should be able to add items to the cart without losing updates
  • Users should be able to place orders for items in their cart
  • The system should handle inventory management to ensure products are in stock

Non-functional requirements:

  • The system should be highly available (users can access the platform at all times)
  • The system should be scalable to handle a large number of users and products
  • Search functionality should have low latency
  • The shopping cart should maintain consistency across multiple sessions and users
  • Order placement should be reliable and handle race conditions for inventory

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

  • Approximately 1 billion users
  • Around 100 million products in the catalog
  • Each product requires approximately 1KB of storage for metadata
  • Approximately 100 million orders placed per day
  • Product search needs to handle high query volume with low latency

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

  • Search service with indexing capabilities
  • Shopping cart service with conflict resolution
  • Order processing service
  • Inventory management system
  • Product catalog database
  • User/account management
  • Maintaining a fast and relevant search experience
  • Handling cart consistency with concurrent updates from multiple users/devices
  • Managing inventory with high concurrent order placement
  • Scaling the system to handle high traffic and large product catalogs
  • Ensuring data consistency without sacrificing availability

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

  • How would your search service handle a high volume of queries efficiently?
    • Focus: Assess the candidate's answer to "How would your search service handle a high volume of queries efficiently" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • What approach would you take to ensure cart updates aren't lost when multiple users update simultaneously?
    • Focus: Assess the candidate's answer to "What approach would you take to ensure cart updates aren't lost when multiple users update simultaneously" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • How would your system handle inventory management when many users are trying to purchase the same item?
    • Focus: Assess the candidate's answer to "How would your system handle inventory management when many users are trying to purchase the same item" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • What trade-offs did you consider when designing your data storage solutions?
    • Focus: Assess the candidate's answer to "What trade-offs did you consider when designing your data storage solutions" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
  • How would your system scale as the number of products and users grows?
    • Focus: Assess the candidate's answer to "How would your system scale as the number of products and users grows" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

  • Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to search for products based on queries/keywords; Users should be able to add items to their shopping cart; Multiple users from the same account should be able to add items to the cart without losing updates. Establishes the constraints that materially affect Design Simple E-commerce Website, including The system should be highly available (users can access the platform at all times); The system should be scalable to handle a large number of users and products. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
  • Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Search service with indexing capabilities; Shopping cart service with conflict resolution; Order processing service; Inventory management system. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
  • Data and scaling (25%): Uses workload assumptions such as Approximately 1 billion users; Around 100 million products in the catalog to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Search service with indexing capabilities; Product catalog database; Maintaining a fast and relevant search experience. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
  • Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Handling cart consistency with concurrent updates from multiple users/devices; Ensuring data consistency without sacrificing availability; The system should be highly available (users can access the platform at all times). Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
  • Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Managing inventory with high concurrent order placement; Scaling the system to handle high traffic and large product catalogs; Ensuring data consistency without sacrificing availability. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.

Ready to practice this question?

Run a mock system design interview with AI coaching and detailed feedback.