Skip to content
System Designer

Easy · Commerce and retail

Shopping cart

Shoppers browse products, drop things in a cart and come back later from another phone. Browsing is most of the traffic and can be a little old. The cart itself must always show what the shopper just added. Practise this easy system design problem for free with a Google or GitHub account.

The brief

Shoppers browse products, drop things in a cart and come back later from another phone. Browsing is most of the traffic and can be a little old. The cart itself must always show what the shopper just added.

Think of the cart on an online store like Amazon.

Users, scale and requirements

Who uses it
10 million shoppers a month (approx.)
Audience in plain numbers
10,000,000 people per month
Normal peak
≈ 3,000 requests per second
Request mix
Read: 75%; Write: 17%; Sign-in: 8%
Speed for 99 of 100 requests
Read: ≈ 400 ms; Write: ≈ 400 ms; Sign-in: ≈ 1,000 ms
Successful requests
99.9%
Data safety
At most 1 minute of writes may be lost.
Monthly budget
≈ $4,200
Data at rest
≈ 0.5 TB
Where users are
North America: 80%; Europe: 20%
Home region
North America
Waiting deadlines
Read: 900 seconds; Write: 3,600 seconds; Sign-in: 900 seconds
Minimum retained history
30 days on authoritative stores
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • Use the write share to estimate peak cart changes.
  • A cart is a few KB (approx.).
  • All numbers are rough approximations.
  • Scored data retention: at least 30 days on active authoritative stores. Copies used only for search or reports can be rebuilt. Local device history and rollup policies still require the separate protocol check.

Questions that shape the design

Can the product pages be a little old?

Yes, by a minute or two. A price that changes is fixed at checkout.

Can the cart be old?

No. If someone adds a shirt and the page reloads without it, they leave.

How long does a cart live?

About 30 days. Most carts are never bought (approx.).

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 12:00 · Flash crowd

    A scheduled launch brings a sudden rush of requests.

    Traffic reaches 2.5 times the scheduled load; rises over 30 seconds, holds for 900 seconds and eases over 1,800 seconds.

  2. 20:00 · Cache stampede

    The cache empties (restart, purge, mass expiry) and every request rushes to the database at once.

    Recovery window: ≈ 300 seconds.

What a strong design has to handle

  • Product pages and the cart have different promises. Which one may be a minute old?
  • A longer cache time saves the catalog database but can show an old price. A minute is a good middle.
  • A key-value store scales carts easily, but you cannot ask it questions like "who has this item in a cart".

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems