Non-Functional Requirements

Start here: 'Design X' is unbounded until you fix the numbers#

An interviewer says 'Design Twitter.' If you open your mouth and start naming databases, you've already lost, because you don't yet know what you're designing. Twitter for a thousand internal users fits on one server with a plain SQL database. Twitter for 300 million daily users needs sharding, caching, fan-out pipelines, and multiple data centers. Same feature list, opposite machines. The feature list didn't tell you which one to build. The numbers did.

Those numbers come from five questions, and you should ask them out loud before you draw a single box. How much scale — how many users, how many reads and writes per second, how much data, growing how fast? How fast — what response time do users actually feel, and where does it start to hurt? How available — how much downtime a year can the product survive? How consistent — when two people read the same thing at the same moment, must they see the identical value, or is a slightly stale answer fine? How durable — if a disk dies, can you afford to lose any of this data, and how much? Answer those five and the problem stops being 'Design Twitter' and becomes 'Design a system that serves 200,000 reads per second at under 200 milliseconds, stays up 99.9% of the year, and never loses a posted tweet.' That second sentence you can actually engineer.

The NFR menu, one line each#

There's a short, standard menu of non-functional requirements. You won't quote all of them for every problem — you pick the two or three that dominate — but you should know each by name and be able to make it concrete. Vague targets ('it should be fast, and scalable') are worthless; a target is only useful once it's a number.

• Scale — the size of the load. Measured in daily active users (DAU, the count of distinct users in a day), reads and writes per second (QPS, queries per second), total data stored, and the growth rate. Everything else is sized off these numbers.
• Latency — how long one request takes, from the user's point of view. Quoted as percentiles: p50 (the median, the time half of requests beat) and p99 (the time 99% of requests beat, i.e. the slow tail). Rough human thresholds: under ~100 ms feels instant, ~1 second is a noticeable pause, past a few seconds users leave.
• Availability — the fraction of time the system is up and serving. Quoted in 'nines': 99.9% ('three nines'), 99.99% ('four nines'). Each extra nine cuts allowed downtime by 10x and costs far more than the last.
• Consistency — whether every reader sees the latest write. Strong (also called linearizable) means a read always returns the most recent write, as if there were one copy. Eventual means copies converge after a short delay, so a read can briefly return stale data. Which one you need is per-feature, not per-system (see the consistency-models topic for the full spectrum).
• Durability — the promise that committed data survives failures. A disk dies, a data center loses power — is any acknowledged write allowed to vanish? Sized with RPO (recovery point objective: how much recent data you can afford to lose, e.g. 'up to 5 minutes') and RTO (recovery time objective: how long you can be down before recovering).
• Throughput — the sustained volume the system processes, e.g. writes per second ingested or messages per second delivered. Latency is 'how long one request takes'; throughput is 'how many you handle at once.' A system can be low-latency and low-throughput, or the reverse.
• Cost — the budget, in machines and dollars, that all of the above has to fit inside. It's the constraint that stops you from just buying more nines. Every target above is really 'the best I can do for this money.'

Two of these you should compute in front of the interviewer rather than guess, because the arithmetic is the point. Scale in QPS falls out of DAU. Say 10 million daily active users, each doing 20 writes a day: that's 200 million writes a day, and 200,000,000 divided by 86,400 seconds is about 2,300 writes per second on average. Traffic isn't flat, so multiply by a peak factor of 3 to 5 for the busy hour — call it roughly 10,000 writes per second at peak. Reads usually dominate writes by 10x or more, so reads land near 100,000 per second. Those three numbers — average write QPS, peak QPS, read QPS — decide whether one database survives or you need sharding and caches. Deriving them out loud, instead of asserting 'it's high scale,' is the difference between engineering and hand-waving.

The two tables you must know cold#

Two lookup tables come up in almost every interview, and fumbling them reads as not having done the reps. The first turns an availability target into concrete downtime. When you say 'four nines,' you're promising the system is down no more than about 52 minutes across an entire year — know what each nine actually buys.

Read the table as a cost curve, not a menu of equals. Going from 99% to 99.9% removes a couple of days of downtime and is often just good engineering — health checks, retries, a standby. Going from 99.99% to 99.999% removes about 47 minutes over a whole year, and buying it means redundant everything, multi-region failover, and automation that recovers in seconds because no human can react inside a five-minute annual budget. The last nine can cost more than all the previous ones combined, which is exactly why you don't reach for five nines by reflex.

The second table is about why you quote latency as p99 and not as an average. The average hides the tail — the slow requests — and the tail is exactly what users remember. Take a service where 99 out of 100 requests return in 20 ms and 1 returns in 2,000 ms. The average is about 40 ms, which looks great and is a lie: one in every hundred users waited two full seconds. The average smeared that pain across everyone until it disappeared. Percentiles refuse to hide it.

The tail matters more the bigger you get, because of a simple multiplication. Suppose loading one page makes 100 backend calls, and each call independently has a 1% chance of hitting the slow p99 path. The chance that all 100 are fast is 0.99 to the 100th power, about 37%. So roughly 63% of page loads touch at least one slow call. A tail that hits '1 in 100 requests' becomes 'the majority of page loads' once a page fans out. That's why serious systems commit to a p99 target, not an average — and why 'our average latency is 40 ms' is a number that should make an interviewer suspicious, not satisfied.

Every target has a price — pick the weakest that works#

NFRs are not free wishes; each one you tighten spends something real. The skill isn't asking for a lot — anyone can ask for a lot. The skill is asking for the least the product can live with, because the least is the cheapest and simplest thing that still works.

• Each extra nine of availability costs a multiple in money and complexity: more replicas, more regions, more automation, more things that can themselves break.
• Strong consistency costs latency and availability. To guarantee every reader sees the latest write, the copies must coordinate before answering, which adds round-trips and means a network partition can force the system to reject writes rather than diverge.
• Lower latency usually costs money and consistency: caches, read replicas, and edge locations cut response time but serve data that can be slightly stale.
• Higher durability costs latency and throughput: waiting for a write to be safely replicated to several machines before acknowledging is safer and slower than acknowledging from one.
• Over-specifying any target over-builds the system. Five nines and strong-everywhere on a feature that needed three nines and eventual consistency means a machine that's more expensive, more complex, and more failure-prone than the product ever required.

The consistency-vs-availability tension has a name worth dropping once, plainly. CAP says that during a network partition (when parts of the system can't talk to each other) you must choose: stay consistent and refuse some requests, or stay available and serve possibly-stale data. PACELC spells the whole trade out: if there's a Partition, choose Availability or Consistency (that's CAP); Else — in normal operation, no partition — you still trade Latency against Consistency, because stronger consistency means more coordination means slower responses. So consistency isn't only a partition-time question; it's a tax on latency all the time.

All of which collapses into one rule you can say out loud and then apply to every feature: pick the weakest target that still meets the product need. Not the strongest you can imagine — the weakest that's genuinely acceptable. Then, when you tighten one deliberately (this balance must be strongly consistent), you can name exactly what you're paying for it, which is precisely the reasoning an interviewer is listening for.

Same system, different targets per surface#

The clearest sign a candidate understands NFRs is that they refuse to give the whole system one set of numbers. A real product is several surfaces with different needs, and the targets are per-surface. The two axes this shows up on most are consistency and latency.

Notice the same distinction repeats. Where a stale read causes harm (money, uniqueness), you pay for strong consistency and synchronous latency. Where it doesn't (counts, feeds), you take eventual consistency and spend your budget on speed instead. And the latency axis splits the same system too: the user-facing read path is latency-critical and measured in milliseconds, while the analytics pipeline behind it is a batch job measured in throughput — it can take minutes as long as it processes everything. One product, several NFR profiles, each derived from what that surface actually needs.