Design a Shopping Cart Service

Hard45 min
1 / 30
System design answer

Design a Shopping Cart Service

Hard45 min30 sections
understanding•10 min read

Problem Statement: The Cart Is a Write-Hot, Always-Available State Machine

Frames the shopping cart as a durability and concurrency problem, not a simple CRUD list.

Problem statement

Design a shopping cart service that stores, updates, and retrieves user carts for an e-commerce platform. The service must support adding and removing items, adjusting quantities, guest and registered carts, merging a guest cart into an account at login, synchronizing the same cart across devices, validating inventory in near real time, computing prices with discounts, and handing a frozen cart snapshot to checkout without losing the user's intent.

The cart looks trivial until you examine its traffic shape. It is the most write-hot personal state in the entire commerce funnel: every add, quantity change, and removal is a write to a per-user record that must survive device loss, browser clears, and regional failures, and must be readable in tens of milliseconds during the highest-traffic days of the year. Amazon's original Dynamo paper chose the shopping cart as its canonical example of an always-writable application: a cart must accept writes even when replicas disagree or networks partition, and conflicts are resolved at read time rather than by rejecting the customer's click.

Why the cart is distinctive

A cart is not a cache and not merely a session blob. It is semi-durable personal state with money attached: users expect a cart to survive weeks, across phones and laptops, and to be identical everywhere. At the same time it must never block: a failed add-to-cart during a flash sale is direct lost revenue. The design therefore separates three planes. The hot state plane keeps the live cart in a low-latency store with per-cart atomicity. The durability plane persists cart contents asynchronously so a cache outage does not erase intentions. The correctness plane owns inventory validation, pricing, and the checkout handoff, where stronger consistency rules apply than in the cart itself.

What this answer assumes

Unless tied to a named public source, every number below is an explicit design assumption for a mature marketplace: 40M DAU, 120M MAU, 55M live carts (35M registered, 20M guest), 7 cart operations per active user per day, a 4:1 read-to-write ratio, a 12x flash-sale peak and a 25x Black Friday peak, and an average cart payload of 1.8KB with 12 line items. Public anchors used for context: Amazon's Dynamo paper describes cart-style always-writable state with vector clocks; Alibaba published a 583,000 transactions-per-second peak for Double 11 in 2020 with a Tair-based cache fleet; Shopify published 9.3 billion USD of Black Friday Cyber Monday GMV in 2023 on a MySQL-plus-Redis storefront stack; eBay's published architecture partitions Oracle databases per user so each shopper's cart lives in one pod.

The four hardest sub-problems

  1. Always-writable carts with concurrent multi-device edits and a sane merge rule.
  2. Guest-to-registered cart merge at login without duplicates or lost lines.
  3. Inventory truth: show scarcity honestly, prevent oversell at checkout, without locking stock for every idle cart.
  4. Price freshness: prices and promotions change under a live cart; checkout must reprice transparently.

Everything else — APIs, shards, caches, queues — exists to serve those four.

Key Highlights

  • •The cart is the most write-hot personal state in commerce: assumed 650 writes/sec average and 16K writes/sec at a 25x peak.
  • •Amazon's Dynamo paper uses the shopping cart as the canonical always-writable, conflict-on-read application.
  • •Three planes: hot state (low latency), durability (async persistence), correctness (inventory, price, checkout).
  • •Assumed scale: 40M DAU, 55M live carts, 1.8KB average payload, 4:1 read-write ratio, 25x Black Friday peak.
  • •Four hard problems: concurrency and merge, guest conversion, inventory truth, price freshness.
Open With Always-Writable
State in the first two minutes that a cart must accept writes during partitions and reconcile later, exactly as Amazon's Dynamo paper argues. It instantly signals you understand commerce state, not generic CRUD.
Do Not Design a CRUD List
A cart designed as a simple database table ignores merge semantics, guest identity, price drift, and flash-sale write bursts. Interviewers probe those, not the INSERT statement.

Section Rescue Kit

Buzzwords to use:

Always-Writable StateWrite-Behind Persistence

Safe statements:

  • "Let me separate the cart's hot state, its durability, and the correctness rules that only checkout enforces."
  • "Before choosing stores, I will classify cart data by write rate, survival requirement, and consistency need."
Design a Shopping Cart Service - System Design | WinJob | WinJob