Design an E-Commerce Platform with Reliable Checkout

Design an e-commerce platform. Explain how customers find products, maintain a cart, place orders, and see the outcome of checkout while the platform keeps product availability, payments, and order state consistent. ### Constraints & Assumptions - The source provides the e-commerce system-design topic without a feature list or scale target. - **Practice scope:** physical products with purchasable variants identified by SKU, a product catalog, product search, a cart, checkout, inventory, payment through an external provider, and order-status lookup. Use these assumptions to make the discussion concrete; they are not reported company requirements. - Exclude recommendations, marketplace seller settlement, and detailed warehouse routing from the core design. - No traffic volume, availability target, geographic footprint, or latency budget is supplied. Explain how these facts would affect your design rather than asserting numeric requirements. - The platform must cope with concurrent purchases of the same SKU and retries of a checkout request or payment notification. ### Clarifying Questions to Ask - Is inventory reserved while items are merely in a cart, or only after checkout begins? - Can prices or availability change between adding to a cart and submitting an order? - Does the payment provider support idempotent requests, authorization followed by capture, and authoritative status queries? - May an order contain several SKUs, and must reservation succeed for the entire order? - Which parts of product browsing may be stale, and which decisions must use authoritative data? ### Part 1 — Define the Read and Write Paths Describe the components and records needed for catalog browsing, search, cart changes, checkout, and order lookup. Identify the source of truth for product price, inventory, and order state. #### What This Part Should Cover - Separation of searchable catalog projections from authoritative checkout data. - Product variants, cart entries, immutable order-line snapshots, and order identity. - Request boundaries that keep customer data scoped to its owner. ### Part 2 — Make Checkout Correct Walk through checkout for an order containing more than one SKU. Explain inventory reservation, price validation, payment initiation, success and failure handling, and duplicate requests. #### What This Part Should Cover - An atomic decision about reservable stock and an explicit order state machine. - Idempotency for customer checkout requests and provider notifications. - Recovery when payment succeeds but the local process loses the acknowledgment, without charging twice or selling the same unit twice. ### Part 3 — Scale and Operate the Platform Explain how you would scale browsing separately from checkout, handle a heavily demanded SKU, and detect orders stuck between payment and fulfillment. #### What This Part Should Cover - Caching and search indexing with a clear boundary around authoritative purchase decisions. - Contention on scarce stock, durable asynchronous work, and backpressure. - Reconciliation between inventory, order state, and the payment provider. ```hint Separate the cart from a purchase A cart may outlive a price change or another customer's purchase of the last unit. Decide which values must be checked again at checkout. ``` ```hint Consider the lost payment response The provider may have accepted a payment even when the application times out. Decide what identity and durable state are needed before trying again. ``` ### What a Strong Answer Covers - A coherent catalog-to-order architecture with a deliberately bounded feature scope. - Inventory and payment invariants that survive concurrency, retries, and partial failure. - Explicit trade-offs between fast browsing, accurate checkout, and contention on popular products. - Operational checks that find inconsistent or stalled orders rather than relying only on request success rates. ### Follow-up Questions - How would you protect a single scarce SKU during a sudden burst of checkout attempts? - What happens if a reservation expires while payment completion is uncertain? - How would the design change if an order's inventory were held in different regions or databases?