system-design-primer
exercise

Amazon sales rank

Design a feature that ranks products by total sales within a category, updated hourly from a stream of sales.

constraints and assumptions
  • 10 million products
  • 1000 categories
  • 1 billion transactions a month
  • 100 billion read requests a month
  • Rank by category recalculated hourly
  • High availability
work it in four steps
in short

The service calculates the past week's most popular products by category and serves that ranking to users.

100 billion reads a month against a ranking that changes hourly is the definition of a cacheable workload.

read: Back-of-the-envelope estimationread: Latency vs throughput
from the primer — step 1: outline use cases and constraints

Gather requirements and scope the problem. Ask questions to clarify use cases and constraints. Discuss assumptions.

Without an interviewer to address clarifying questions, we'll define some use cases and constraints.

Use cases

We'll scope the problem to handle only the following use case

  • Service calculates the past week's most popular products by category
  • User views the past week's most popular products by category
  • Service has high availability

Out of scope

  • The general e-commerce site
    • Design components only for calculating sales rank

Constraints and assumptions

State assumptions

  • Traffic is not evenly distributed
  • Items can be in multiple categories
  • Items cannot change categories
  • There are no subcategories ie foo/bar/baz
  • Results must be updated hourly
    • More popular products might need to be updated more frequently
  • 10 million products
  • 1000 categories
  • 1 billion transactions per month
  • 100 billion read requests per month
  • 100:1 read to write ratio

Calculate usage

Clarify with your interviewer if you should run back-of-the-envelope usage calculations.

  • Size per transaction:
    • created_at - 5 bytes
    • product_id - 8 bytes
    • category_id - 4 bytes
    • seller_id - 8 bytes
    • buyer_id - 8 bytes
    • quantity - 4 bytes
    • total_price - 5 bytes
    • Total: ~40 bytes
  • 40 GB of new transaction content per month
    • 40 bytes per transaction * 1 billion transactions per month
    • 1.44 TB of new transaction content in 3 years
    • Assume most are new transactions instead of updates to existing ones
  • 400 transactions per second on average
  • 40,000 read requests per second on average

Handy conversion guide:

  • 2.5 million seconds per month
  • 1 request per second = 2.5 million requests per month
  • 40 requests per second = 100 million requests per month
  • 400 requests per second = 1 billion requests per month
sourcedonnemartin/system-design-primer / solutions/system_design/sales_rank/README.mdsyncedsynced from donnemartin/system-design-primer@master · 2026-08-16
full solution in the primer ↗