Design Shopping Cart System

Hard45 min
1 / 20
understanding5 min read

Problem Statement & Context

What we are building and why it matters

Problem Statement & Context

A shopping cart service stores the intent to purchase before checkout. It must feel instantaneous, survive device changes, and protect inventory from overselling — and it is one of the highest write-QPS surfaces in all of commerce, handling both guest sessions and logged-in accounts.

The cart is a bridge

The cart sits between discovery and checkout, and its job is to freeze intent without freezing inventory. It captures item snapshots, promotions, and delivery options so pricing does not drift between add-to-cart and payment, while deliberately not hard-reserving stock on every tap (which would let abandoned carts starve real buyers).

Why it is deceptively hard

A cart looks like a key-value store but combines five hard problems at once: session management (guest vs registered + merge on login), concurrency (the same cart edited on phone and laptop), inventory validation (soft hints in cart, hard checks at checkout), pricing correctness (price + promo snapshots), and high availability (cart downtime kills conversion directly). The load-bearing idea is a two-speed consistency model: the cart itself is fast and eventually-consistent (AP), while the checkout handoff is strongly-consistent (CP) — speed where mistakes are cheap, correctness where they cost money.

Scale anchors

  • 100M+ daily active shoppers
  • 10–20% of page views are cart mutations
  • 5–10× spikes during sales

These drive cache sizing (the cart lives hot in memory) and the write-behind durability strategy.

Key Highlights

  • A shopping cart stores the INTENT to purchase before checkout — instant, surviving device changes, protecting inventory; one of the highest write-QPS surfaces, handling guest sessions + logged-in accounts
  • The cart is a bridge between discovery + checkout: freeze INTENT without freezing INVENTORY — capture price/promo snapshots so pricing doesn't drift, while NOT hard-reserving stock on every tap (which would let abandoned carts starve real buyers)
  • Deceptively hard: combines session management (guest/registered + merge-on-login), concurrency (phone + laptop), inventory validation (soft in cart / hard at checkout), pricing correctness (snapshots), and high availability (downtime kills conversion)
  • The load-bearing idea is a TWO-SPEED consistency model: the cart is fast + eventually-consistent (AP), the checkout handoff is strongly-consistent (CP) — speed where mistakes are cheap, correctness where they cost money; anchors 100M+ DAU, 10-20% of views are mutations, 5-10× sale spikes
Cart as Conversion Lever
Framing the cart as a conversion-critical system shows business awareness.
Snapshot Pricing
Storing price snapshots in the cart avoids surprises during checkout.
Ignoring Guest Carts
Guest flows are common; designing only for logged-in users is incomplete.
5-Minute Mark
You should transition into clarifying questions now.

Section Rescue Kit

Buzzwords to use:

Cart SnapshotSession PersistenceWrite-Heavy Workload

Safe statements:

  • "I will treat the cart as a write-heavy, conversion-critical system."
  • "I will separate guest and logged-in cart flows explicitly."
Design Shopping Cart System - System Design | WinJob | WinJob