Functional vs. Non-Functional Requirements & Back-of-the-Envelope Estimation

functional vs. non-functional requirements

Before any boxes and arrows get drawn, every design starts by pinning down two different kinds of requirements, and mixing them up is one of the most common early mistakes.

Type	Answers the question	Example (a ride-hailing app)
Functional requirements	What must the system let a user do?	A rider can request a trip; a driver can accept it; both can see a live map.
Non-functional requirements	What qualities must the system have while doing that?	A trip request must resolve to a driver match in under 2 seconds; the service must stay up during a regional outage.

Functional requirements define the feature list. Non-functional requirements — latency, availability, consistency, durability, security — define how hard the feature list actually is to build. Two systems with an identical feature list can require completely different architectures depending on their non-functional targets: "post a comment" is trivial at 100 users a day and a genuinely hard distributed-systems problem at 100 million.

the questions worth asking about the data

Once the feature list is scoped, the next step is understanding the data the system will actually move and store, because the answers steer almost every later decision — which database, whether to cache, whether to shard.

What's the current size of the data, and how fast is it expected to grow?
Is access read-heavy, write-heavy, or roughly balanced?
Does it need strict consistency, or is eventual consistency acceptable?
What's the durability requirement — can any of this data be lost?
Are there privacy or regulatory constraints on how it's stored or transmitted?

back-of-the-envelope estimation

Before committing to an architecture, it's standard practice to run rough numbers — "back of the envelope" — to sanity-check that the plan is even in the right order of magnitude. These aren't meant to be precise; they're meant to catch a design that's off by 1,000x before it's built.

Worked example: a note-taking app expects 5 million daily active users, each averaging 3 note-saves a day, each note-save averaging 2 KB.


Writes per day   = 5,000,000 users × 3 saves        = 15,000,000 writes/day
Writes per second = 15,000,000 / 86,400 seconds      ≈ 174 writes/sec (average)
Peak writes/sec   = average × peak factor (often 2–3×) ≈ 350–520 writes/sec
Storage per day   = 15,000,000 × 2 KB                ≈ 30 GB/day
Storage per year  = 30 GB × 365                       ≈ 11 TB/year

A single modern database server can often handle a few thousand writes per second, so 350–500 writes/sec on its own doesn't demand sharding yet — but 11 TB a year does demand a real storage and archival plan. That's the value of the exercise: it tells you which part of the design actually needs to be hard, and which part is fine to keep simple for now.

what to size, in general

Resource	Typical estimate needed for
Servers / compute	How many app servers to handle peak requests per second, given each server's realistic throughput.
Storage	Total data volume today and its growth rate, to plan disk, replication, and retention.
Bandwidth	Network throughput for data in and out, especially for media-heavy features.
Memory / cache	How much of the "hot" working set can realistically fit in RAM.

These estimates directly justify architecture decisions later in this track — for example, whether a workload's write volume is large enough to need sharding, or small enough that a single well-provisioned database is fine.

reference

System Design Primer (GitHub) — back-of-the-envelope numbers

Functional vs. Non-Functional Requirements & Back-of-the-Envelope Estimation