System design · Day 2
Requirements and estimation: put numbers on the problem
Clarify scope, identify quality goals, and calculate rough traffic, storage, bandwidth, and latency before drawing boxes.
System design begins with questions, not architecture. Requirements tell us what promise the system must keep; estimates reveal which parts of that promise create pressure.
Separate behavior from quality
Functional requirements describe what users can do: create a link, view a feed, send a message. Non-functional requirements describe how the service should behave: target latency, availability, consistency, durability, privacy, and expected scale.
Choose the core journey and explicitly exclude secondary features. A design for direct messages is different from group chat with search and read receipts. Scope is not avoiding complexity; it is making the complexity visible.
Estimate orders of magnitude
Convert daily activity to requests per second by dividing by roughly one hundred thousand seconds, then multiply for peak traffic. Ten million daily reads is about one hundred per second on average; planning for ten times that peak gives a useful first bound.
Estimate storage as records per day × bytes per record × retention. Estimate bandwidth from request rate × payload size. The numbers do not need false precision—they need to distinguish megabytes from terabytes and tens of requests from millions.
Let numbers change the design
A read-heavy product points toward caches and replicas. Large media points toward object storage and a CDN. Strict financial correctness points toward transactions and careful idempotency. Each later lesson addresses one of these pressures.
Keep the estimates beside the diagram and revise them when assumptions change. Day 3 now follows the request through DNS, the network edge, and a load balancer before it reaches our service.
“Back-of-the-envelope math is not prediction; it is a defense against designing for the wrong scale.”