What Non-Functional Requirements Are

Why this matters: almost every candidate can list what a system should do. The ones who get offers can say how well it must do it, and can defend the number. Non-functional requirements are where system design actually happens.

Key takeaway

A functional requirement says what the system does. A non-functional requirement (NFR) says how well it must do it — how fast, how often it's up, how much it can grow, how quickly it recovers. Functional requirements barely constrain your architecture. NFRs determine it almost entirely.

The distinction, concretely

System	Functional requirement	Non-functional requirement
URL shortener	Shorten a URL; redirect to the original	100k redirects/sec at p99 under 50 ms, 99.99% available
Payment API	Charge a card	Never double-charge; correct under retry; auditable forever
Video platform	Upload, search, stream, rate videos	Start playback in under 2 s worldwide; survive a region loss
Chat	Send a message to a user	Deliver in under 200 ms; never lose a delivered message

Look at the middle column. Every one of those is a weekend project. Now look at the right column — that is where the servers, the replication strategy, and the eighteen months of engineering live.

The NFR map

The characteristics this chapter covers, and how they relate:

They are not independent, and that is the whole game:

Fault tolerance is the mechanism; availability and reliability are the outcomes you buy with it.
Maintainability drives availability, because most downtime ends when a human fixes something — and how fast that happens is a property of the system's design.
Scalability protects performance and availability as load grows. A system that can't scale becomes slow first and unavailable second.
Performance and consistency pull against each other, as Chapter 1 established: coordination costs latency.

NFRs are design forces

The point of writing an NFR down is that it forces a decision. If a stated requirement doesn't change your architecture, it wasn't a requirement — it was a wish.

NFR as stated	Useless or useful?	The decision it forces
"It should be fast"	Useless — unfalsifiable	None
"p99 read latency under 50 ms globally"	Useful	Serve reads from the user's region; no cross-region hop on the hot path
"It should be highly available"	Useless — no target	None
"99.99% — about 52 minutes down per year"	Useful	Multi-AZ redundancy, automated failover, no manual recovery step
"It should scale"	Useless	None
"10x traffic in 12 months, spiky"	Useful	Stateless services, autoscaling, queue-based load absorption

The pattern: a number and a unit, or it isn't a requirement. Lesson 10 is entirely about producing those numbers when the interviewer won't give them to you.

Where NFRs come from

You will rarely be handed them. You extract them, by asking:

Traffic — how many users, what request rate, what read/write ratio, how spiky?
Data — how much stored, growing how fast, retained how long?
Latency — what's the user-facing budget, and for which operation?
Downtime tolerance — what does an hour of outage actually cost? Revenue? Safety? Trust?
Correctness — what's the cost of a stale or wrong answer here? (Chapter 1's question, and still the sharpest one.)
Growth — what does this look like at 10x? At 100x?

The ranking exercise

Because you cannot maximize everything, ranking is the actual skill: