Requirements and napkin math

System Design · lesson 2 of 32 · 4 min read

Turn a vague prompt into functional requirements, non-functional targets, and rough numbers.

Open this lesson in the learning hub

Key points

  • Functional = what it does. Non-functional = how well: latency, availability, durability, consistency, cost.
  • Pin four numbers early: daily active users, actions per user per day, read:write ratio, bytes per record. Everything follows from these.
  • 1M requests/day is about 12/s. 100M/day is about 1,200/s. Peak traffic runs 2-5x the average, so design for peak.
  • Storage = bytes per record × records per day × retention. 1 KB × 1M/day is about 1 GB/day, so ~365 GB/year.
  • Round hard. 86,400 seconds in a day is ~100k. Nobody wants to watch you do long division.
  • Latency anchors: memory read ~100 ns, SSD read ~100 µs, same-datacentre round trip ~0.5 ms, cross-continent ~100 ms.

Read-heavy means caches and replicas; write-heavy means sharding and queues. The ratio picks the architecture.

How to run a design interview Scaling out behind a load balancer

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the System Design course, and every lesson in it is listed on the System Design contents page.