Functional vs Nonfunctional Requirements

Functional vs Nonfunctional Requirements

Every system-design interview opens the same way: "Design a URL shortener," or "Design Twitter's timeline." The prompt is deliberately vague. Before you draw a single box, you must split the problem into two kinds of requirements, because they are answered by completely different parts of your design.

Functional requirements (FRs) describe what the system does — the features, the verbs, the observable behavior a user or client can name. "Given a long URL, return a short code" or "resolve a short code back to the original URL and redirect." If a product manager can write it as a user story, it is functional.

Nonfunctional requirements (NFRs) describe how well the system must do those things — the qualities: latency, throughput, availability, durability, consistency, cost, security, scalability. Nobody asks for "99.99% availability" as a feature, yet it dictates almost every hard architectural choice you make. The concept exists to stop you from building something that technically works but falls over at 10,000 requests per second, loses data on a crash, or takes two seconds to load.

How it works, precisely

The mechanism is a mapping: FRs map to your API surface and data model; NFRs map to your infrastructure and topology. They are elicited and used differently.

• FRs → the API and schema. Turn each verb into an endpoint: POST /shorten, GET /{code}. Turn each noun into an entity: a mappings table of (short_code, long_url, created_at, owner_id). FRs answer "is the feature present and correct?" — they are usually binary (works / doesn't).
• NFRs → the topology. A read latency target pushes you toward a cache; a durability target pushes you toward replication; a throughput target pushes you toward sharding and load balancers; an availability target pushes you toward multi-region failover. NFRs answer "is it good enough under load and failure?" — they are measured on a continuum against a target (an SLO).

Critically, NFRs are the ones with tension between them. You cannot maximize consistency, availability, and partition-tolerance at once (CAP); you trade low latency against strong consistency; you trade cost against redundancy. That tension is where senior-level judgment lives — and why interviewers weight NFRs so heavily. FRs tell you which boxes to draw; NFRs tell you how many of each box and how they connect.

A worked scenario: the URL shortener

Say the interviewer gives you 100 million new URLs per day with a 100:1 read-to-write ratio. Watch how each requirement type drives a different decision.

Functional side (unaffected by scale): shorten a URL, redirect on lookup, optionally support custom aliases and expiry. These endpoints look identical whether you serve 100 users or 100 million.

Nonfunctional side (where the numbers bite):

• Write throughput: 100M/86,400s ≈ 1,160 writes/sec average. Traffic is diurnal, so design for peak — and say the peak factor out loud as an assumption to negotiate: "I'll assume peak ≈ 2–3× average unless you have data." At 3× that is ~3,500 QPS. Know when the assumption is wrong: flash sales and celebrity events can put 10× on the hot path, and that is a different design conversation.
• Read throughput: 100× that → ~116,000 reads/sec average. A single Postgres box cannot serve this; you need a cache (Redis) fronting the DB, absorbing 95%+ of reads.
• Storage: 100M/day × 365 × 5 years × ~500 bytes/row ≈ ~90 TB. That will not fit on one node — you shard by short_code.
• Latency: a redirect should feel instant, so target p99 < 50 ms. That is why the read path is cache-first, not DB-first.
• Availability: a dead redirect breaks every link ever shared, so target 99.99% (~52 min downtime/year) → replicate, no single point of failure.

The FR "redirect a short code" is one sentence. The NFRs behind it just forced a cache tier, a sharded datastore, replication, and a load balancer into your diagram.

Trade-offs: when to lead with which

The two are not alternatives you choose between — every system has both — but you allocate design time between them, and getting the balance wrong is the failure mode.

• Lead with FRs when the domain logic is the hard part and scale is modest: an internal admin tool, a workflow engine, a billing calculator with tricky rules. Here 500 QPS fits on one well-provisioned box, so obsessing over sharding is wasted effort — correctness of the rules is the whole game. Nail the FRs and data model first.
• Lead with NFRs when the feature set is small and well-understood but the scale, latency, or availability is the challenge — which is most interview prompts (news feed, chat, rate limiter, ad server). The verbs are obvious; the interviewer is testing whether you can hit the numbers. Spend 70% of your time on the NFR-driven topology.
• Versus "just build it and optimize later": that works for FRs (you can add a feature incrementally) but is dangerous for NFRs. Availability and consistency guarantees are architectural — retrofitting strong consistency or multi-region failover onto a design that assumed a single node often means a rewrite. NFRs must be decided up front precisely because they resist late change.

The senior signal is stating NFRs as quantified SLOs with a rationale ("p99 < 200 ms because it's a user-facing feed; 99.9% because a brief outage is tolerable and the fourth nine approximately doubles the cost — the redundancy derivation below shows why") rather than reciting adjectives like "fast" and "scalable."

Pitfalls an interviewer probes

• Jumping to boxes before pinning NFRs. If you draw a cache before anyone said the read:write ratio, the interviewer will ask "why?" and you'll have no number to point to. Always negotiate the NFRs (scale, latency, availability, consistency) out loud first — this is often 60% of the score.
• Unquantified NFRs. Saying "it should be highly available" is a red flag. Say "99.99%, which is ~52 minutes/year, so no single point of failure and multi-AZ." Numbers turn a wish into a design constraint.
• Treating consistency as an NFR you can max out for free. Interviewers love to push here: "Do you need strong consistency on the redirect?" The right answer recognizes it's a trade-off against availability and latency (CAP/PACELC) — a URL shortener is fine with eventual consistency and stale cache reads; a bank ledger is not.
• Misclassifying requirements. Security and compliance often get dropped, but "URLs must expire" is functional while "resist enumeration of codes" is nonfunctional (security). Being able to sort a fuzzy requirement into the right bucket signals clear thinking.
• Over-engineering the FR path for scale that isn't there. The mirror-image mistake: sharding a 200-row config table. Match the NFR effort to the stated numbers.

Operationalizing NFRs: SLI, SLO, SLA, and error budgets

In production, NFRs are not adjectives — they are measured contracts:

• SLI (Service Level Indicator) — the raw metric you measure (e.g. fraction of redirects with latency < 50 ms, or successful requests / total requests).
• SLO (Service Level Objective) — the target on that SLI over a window (e.g. 99.9% of redirects meet p99 < 50 ms over 30 days).
• SLA (Service Level Agreement) — the customer-facing promise with consequences (credits, penalties) if you miss; usually looser than the internal SLO.
• Error budget — the allowed miss rate (1 − SLO). If the budget is exhausted, freeze risky deploys and spend engineering time on reliability until the budget recovers.

Translation example (URL shortener): NFR “redirects feel instant and almost never fail” becomes SLI = count(latency < 50ms AND status=301/302) / count(redirects), SLO = 99.9% over 30 days, error budget = 0.1% ≈ ~43 minutes of bad redirects per month at constant traffic. That single SLO forces the cache-first topology; burning the budget freezes feature launches until cache hit rate and tail latency recover.

What a nine actually costs

The interview follow-up is always "why does the fourth nine double the cost?" — so derive it instead of asserting it. A single node at 99.9% availability is down with probability 0.001. Put a second, independent replica behind failover and both are down together with probability 0.001 × 0.001 = 10⁻⁶ — the pair is at 99.9999%. That arithmetic is why the jump from 99.9% to 99.99% is bought with a second replica in another AZ: you pay roughly 2× the infrastructure, plus the parts the multiplication hides — failover automation (health checks, detection, promotion), the on-call rotation that trusts it, and regular failover testing. Each additional nine repeats the pattern at the next level up (multi-AZ → multi-region), so cost grows approximately with each nine — real cost curves vary by architecture, which is why "doubles" is a rule of thumb, not a law.

The caveat is load-bearing: the (1 − a)² math assumes the two failures are independent. Replicas that share a switch, an AZ, or the same bad deploy fail together, and the derived 99.9999% evaporates. That is why the second replica goes in a different AZ, and why the derived number is a ceiling, not a promise.

And what misclassification costs — the failure case that makes the FR/NFR split concrete:

Same sentence in the prompt; the classification decided whether it cost a design meeting or a quarter.

Key takeaways

• FRs = what (features, verbs) → API + data model, mostly binary. NFRs = how well (latency, throughput, availability, consistency, cost) → topology and infrastructure, measured against SLOs.
• NFRs drive the hard architectural choices — cache, sharding, replication, failover — and they carry the trade-offs (CAP, latency vs consistency, cost vs redundancy) that resist late change, so decide them up front.
• Quantify every NFR and justify the target: "99.99% because a dead redirect breaks every shared link" beats "highly available."
• Allocate time by where the difficulty lives — FR-first for logic-heavy low-scale systems, NFR-first for the scale/latency-driven prompts that dominate interviews.