NFR to Architecture

Show me your feature list, and I know what your system does. Show me your constraints, and I know what it looks like.

Part 3 made a claim it never fully proved: interviewers care more about non-functional requirements, because those drive architecture. Fifteen articles later, we can finally show the machinery.

Bonus A just sharpened the E in C.R.E.D, turning vague scale into numbers. This article sharpens the R: turning vague requirements into the forces that actually decide whether a system needs caching, replication, queues, sharding, encryption, failover… or a much simpler design than anyone expected.

Because here's the puzzle that makes the point: a URL shortener and a banking ledger can both be described as "store a record, look it up later." Same feature shape. Wildly different architectures.

Nothing in the features explains the difference. Everything in the constraints does.

The Simple Mental Model: The Building Code Behind the House

Functional requirements are the rooms in a house: kitchen, bedroom, bathroom, balcony. They're what the client asks for, what the brochure shows, what everyone discusses.

Non-functional requirements are the building code: how much weight the structure must carry, fire safety, earthquake resistance, ventilation, electrical load, water pressure, emergency exits, maintenance access, and the budget.

Nobody photographs the building code. The building code decides everything the photograph can't show: the foundation depth, the beam sizes, the materials, the cost.

Two houses can have identical room lists, and completely different structures, because one sits in an earthquake zone with a strict budget, and the other doesn't.

Two systems can have identical feature lists, and completely different architectures, because their NFRs are different.

The rooms are the brief. The code is the engineering.

Functional Requirements vs Non-Functional Requirements

The clean split: functional requirements describe what the system does. Non-functional requirements describe how well it must do it, and what it must survive.

Notice what the right column is made of: numbers, guarantees, and failure behavior. Notice also that every entry points directly at a design mechanism you now know — Part 6's cache, Bonus E's health checks, Part 8's lifecycle, Part 7's DLQ, Part 11's audit trail.

Features fill the roadmap. NFRs fill the architecture diagram.

Vague NFRs Are Not Requirements

Here are five sentences that appear in real documents and mean nothing: the system should be fast. Scalable. Secure. Highly available. Easy to maintain.

They're not requirements — they're compliments the system hopes to earn. You cannot design toward "fast." You cannot test "scalable." You cannot page anyone about "secure."

Watch what happens when each gets a number:

The transformation is not cosmetic. Each number is now designable (it picks mechanisms), testable (Bonus A's arithmetic can check it), and operable (Part 12 can dashboard and alert it).

In fact — look closely at that right-hand column. Those are SLOs before launch. Part 12's SLI/SLO machinery is how these promises get measured once the system is live; an unquantified NFR is an SLO nobody can ever burn against.

If you cannot measure it, you cannot design, test, or operate against it.

NFRs Are Architecture Inputs

Now the core claim of this article, as a lookup table. Read each row as cause → effect:

This table is why the R comes before the D in C.R.E.D: every architecture component this series taught is the answer to some NFR. No stated NFR, no principled reason for the component — which is how systems end up with Kafka and no one remembering why.

Let's walk the biggest forces one at a time.

Latency NFRs: Why "Fast" Changes Everything

Say the requirement is real: redirect p99 under 100 ms. That single number starts issuing orders: cache placement (the hot mappings must live in memory, Part 6, likely at multiple layers), CDN / edge (if users are global, physics demands the answer live near them, Part 4), database query design (one indexed lookup; anything scanning is disqualified), API response size (a redirect carries almost nothing, keep it that way, Part 10), synchronous hop count (every downstream call spends the budget, Bonus A's latency table — at 100 ms, the redirect path can afford almost none), sync vs async (analytics, counting, logging: all of it leaves the hot path and goes through Part 7's queues), and precomputation (anything that can be computed before the request, must be).

And one order most teams miss: the p99 target makes tail-latency observability mandatory (Part 12) — you can't defend a percentile you don't chart.

A latency NFR isn't a wish. It's a budget, and budgets discipline everything they touch.

Availability, Reliability, Durability — and the Two Numbers That Define Recovery

Four words that get blended; four different promises. Availability: can users access the system right now? (Part 8's distinction: reachable.) Reliability: does it behave correctly over time? A system can be up and wrong. Durability: is the data not lost? (Part 8: an ack is only as strong as what's replicated.)

And when things go wrong, two numbers define the contract with disaster. RTO — Recovery Time Objective — is how long the system may be down before it's recovered. RPO — Recovery Point Objective — is how much data loss is acceptable, measured as time since the last recoverable moment.

Watch them command architecture:

RTO = 30 minutes  →  standby capacity + failover that's been REHEARSED,
                     runbooks (Part 12), health checks and draining (Bonus E)
                     — because a 30-minute promise dies in a 3-hour restore

RPO = 5 minutes   →  replication or backups capturing changes at least
                     every 5 minutes — near-continuous shipping (Bonus I)

RPO = 0           →  synchronous replication: Bonus F's EC choice,
                     paid for in write latency, on purpose

Availability NFRs pull in the same direction: redundancy everywhere a single failure could violate the number — replicas (Bonus I), multiple instances behind health-checked balancing (Bonus E, Part 9), and at the strictest tiers, multi-region design. Durability NFRs pull on Part 8: replication or erasure coding, backup frequency derived from the RPO, archives per retention, and the restore drill, because a backup that's never been restored is a hope with a schedule.

And the Quieter Force: Scalability

Scalability NFRs — "support 10× growth without redesign" — are why Part 9 demanded stateless compute, why horizontal scaling and its load balancing exist (Bonus E), why write growth forces sharding conversations early (Bonus G), and why queues absorb the bursts autoscaling can't catch (Part 7). A scalability NFR is a promise about the future's traffic, which is exactly why Bonus A's growth estimates feed it.

Consistency NFRs: What Can Be Stale, and For How Long?

Bonus F gave this NFR its question, and it remains the sharpest sentence in the series: "What can be wrong, for whom, for how long — and how do we recover?"

Answered per data type, it is the consistency requirement. Comfortable being eventual: analytics dashboards, like counts, recommendations, search indexes — Bonus I's whole acceptable-lag column. Usually needing strength: payments, wallet balances, permissions, final booking confirmation, compliance-critical records — the money/trust/safety column.

And the consistency NFR, once written down, issues its own orders: primary vs replica routing per read (Bonus I), cache TTLs per dataset (Part 6's freshness dial — a TTL is a consistency NFR with a number on it), which workflows may go async (Part 7), where reconciliation jobs must exist to repair the eventual paths, what the UI honestly shows during the window ("updating…"), and where real transaction boundaries are non-negotiable.

One system. Many consistency NFRs. Chosen per data, never per database.

Security, Privacy, and Compliance NFRs

The weakest security requirement in the industry is two words long: "add auth."

Part 11 showed what the real requirement decomposes into, and each piece is an NFR with architectural consequences: who authenticates and how (users, services, machines — token lifetimes included), the authorization model (RBAC, ABAC, scopes — chosen by the actual rules), tenant isolation (enforced from the verified token, on every query), encryption in transit and at rest (Part 11's armor, including backups and logs), secrets management (vault, rotation cadence as a number: "every 90 days"), and audit obligations (which actions, retained how long, protected how).

Privacy and compliance add the requirements engineers forget until legal remembers: data retention ceilings as well as floors, data deletion on request (which quietly constrains every copy from Part 6's caches to Part 8's archives to Bonus I's replicas), least privilege, and periodic access reviews.

The point: security NFRs define trust boundaries, access rules, audit obligations, and sensitive-data handling — in writing, with numbers, before the design. "Add auth" is a room. This is the building code.

Observability and Operability NFRs

Part 12 ended with a checklist. Here's its promotion: those items are requirements, stated before the system exists. Every request carries a correlation ID. A p95/p99 dashboard exists per user journey. Cache hit rate is tracked; queue depth and DLQ size are alerted. Security events are audit-logged. Every critical alert has a runbook. SLO burn alerts exist for the journeys that matter.

And its twin, operability: can humans actually run this under stress? On-call readiness, safe deploys and rollbacks (Part 9's blast radius), drills that tested the runbooks — maintainability's 2 AM edition.

A system that meets every performance NFR but can't be understood during an incident has failed a requirement. It just failed one nobody wrote down.

Cost as an NFR

The constraint that outranks all others when violated, because it's the only NFR with a termination clause.

Cost requirements shape: managed vs self-managed choices (operational cost is cost), storage tiers and retention (Part 8's lifecycle rules), caching strategy (Part 6 and Bonus A: the CDN hit rate is a financial instrument), autoscaling limits (Part 9's over-scaling doesn't page anyone, it invoices them), log and telemetry volume (Part 12's sampling and cardinality budgets), egress control (Part 8's classic shock), and the biggest lever of all: not over-engineering for scale the business hasn't earned (Bonus A's expressway for forty scooters).

A technically impressive architecture that the business cannot afford is not a good architecture. It's an expensive rehearsal for the redesign.

When NFRs Conflict

Here's the part that makes architecture a judgment discipline rather than a lookup table: the forces push against each other.

Low latency vs strong consistency — Bonus F's entire ELC trade. High availability vs strict consistency — CAP's partition-day choice. Durability vs cost — every extra replica is a bill (Part 8). Security vs usability — every factor of authentication is friction, on purpose. Observability vs privacy and cost — telemetry wants everything; Part 11 and the invoice say no. Scalability vs simplicity — Part 2's oldest warning, Part 9's microservices tax. Low cost vs high redundancy — the RPO you want vs the RPO you'll pay for. Fast delivery vs long-term maintainability — this quarter vs every quarter after.

Which produces the honest definition: architecture is not satisfying every NFR perfectly. Architecture is deciding which NFR wins in which situation, and writing the decision down.

Which kind of conflict you're in — physics, business, or team maturity — changes how you resolve it. That taxonomy is Bonus C, next.

Turning NFRs into Architecture Decisions: The URL Shortener

The dress rehearsal for Blog 13, continuing from Bonus A's numbers. Requirements today; boxes next time.

Functional requirements (the rooms): a user can create a short URL, and a user can redirect from a short URL to the original.

Non-functional requirements (the building code):

Redirect p99            < 100 ms
Read/write ratio        100:1            (Bonus A's estimate, promoted to a requirement)
Availability            99.9% for redirects
Retention               3 years
Consistency             eventual is fine for analytics; redirects must not serve wrong URLs
Privacy                 no sensitive data in short-URL logs

And the architecture pressure each one applies: p99 < 100 ms leads to caching the hot mappings (Part 6, Bonus A's 18 GB hot set), with the redirect path avoiding heavy synchronous dependencies. The 100:1 ratio leads to a read-optimized path for redirects, with the write path staying simple. 99.9% availability leads to replicas and health-checked balancing on the read path (Bonus I, Bonus E). 3-year retention leads to mappings in a durable store with lifecycle thinking (Part 8) — Bonus A already showed it's only ~½ TB. Eventual analytics leads to clicks counted asynchronously (Part 7), never in the redirect's latency budget. Privacy leads to logs scrubbing sensitive query parameters (Parts 11, 12). And the p99 promise itself leads to observability tracking redirect latency and cache hit rate from day one (Part 12).

Six constraints. Seven design decisions. Zero boxes drawn yet — and the architecture is already three-quarters determined.

Write Them Down

One habit completes the R: the NFR block in the design doc. Per user journey: latency target (p99), availability, consistency per data type, retention, audit needs, cost ceiling — each measurable — plus one line naming which trade-off was chosen and why. Reviewers can argue with a number. Nobody can argue with "scalable."

In C.R.E.D terms: Clarify found the actors and the problem; Requirements is where the constraints get numbers; Bonus A's Estimate checks them against arithmetic; and Design, finally, has something real to answer to.

A good architect does not ask only, "What features should the system have?" A good architect asks, "How fast, how available, how secure, how scalable, how consistent, how observable, how recoverable, and at what cost must this system be?"

Common Mistakes Engineers Make with NFRs

Treating NFRs as documentation after design — the building code, consulted after construction. "Scalable, secure, fast," no numbers — compliments, not requirements. Ignoring p95/p99 — Part 12's lesson: the average is where pain hides. Designing only for features — all rooms, no foundation. Assuming all data needs the same consistency — Bonus F's per-data lesson, skipped. Ignoring RTO/RPO — discovering the recovery contract during the disaster. Ignoring cost — the NFR with a termination clause. Ignoring observability and operability — a system nobody can run under stress has failed silently. Over-engineering for unrealistic NFRs — five nines for an internal dashboard. Under-engineering because NFRs were never asked — the footpath meeting the highway. Not documenting which trade-off won, and why — the next team re-fights every settled war. Security equals login — a room, mistaken for the code. Never revisiting NFRs after production — Bonus A's calibration rule applies to requirements too, the dashboards now know the truth.

From My Journey: An Architectural Lesson

Many system discussions start with features — what screens exist, what APIs are needed, what tables to create. It's a natural place to start; features are what everyone can see and everyone can discuss.

And the first architecture that comes out of those discussions often looks correct. Every feature is covered. Every box has a purpose. The review goes well.

Then real usage arrives, and the missing constraints introduce themselves one at a time: the latency target nobody set, the availability expectation nobody quantified, the audit need nobody mentioned, the retention rule nobody planned storage for, the cost ceiling nobody stated, the operational visibility nobody required.

The realisation that reframes the whole exercise: features describe the system's behavior. NFRs describe the pressure under which that behavior must survive. A design can satisfy every feature and still be wrong for its constraints — the same rooms, built without the building code.

And every constraint, once stated, turned out to be a trade with teeth. Optimizing for latency traded freshness. Strict consistency traded speed or availability. Redundancy traded cost. Simplicity traded scale headroom. There was never a design that won every force — only designs honest about which force won where.

The lesson that stuck: NFRs are where architecture actually begins.

Functional requirements tell us what to build. Non-functional requirements tell us what the system must survive.

Key Takeaways

• Features are the rooms; NFRs are the building code — same feature list, different constraints, different architecture.
• "Fast, scalable, secure" are compliments; requirements have numbers. Unmeasurable NFRs can't be designed, tested, or operated against.
• A measurable NFR is an SLO before launch — Part 12's machinery is how it gets verified.
• Every component this series taught is the answer to some NFR; no stated NFR, no principled reason for the component.
• Latency targets are budgets that discipline everything: caches, hop counts, precomputation, async offloading.
• RTO and RPO are the two numbers that turn "disaster recovery" from a slide into an architecture — and RPO = 0 has a price tag Bonus F already explained.
• Consistency is an NFR per data type: what can be wrong, for whom, for how long, and how do we recover.
• Security NFRs define trust boundaries, audit obligations, and rotation cadences — "add auth" is a room, not a code.
• Cost is the NFR with a termination clause; unaffordable architecture is a rehearsal for the redesign.
• NFRs conflict by nature — architecture is choosing which one wins where, and writing the decision down.

Interview Lens

Here's the move that separates candidates in the first two minutes of any "design X" prompt: before drawing anything, ask for the numbers.

"Before I design — what's the latency target, and at which percentile? What availability are we promising? Which data must be strongly consistent, and which can be eventual? Any retention or audit requirements? Is there a cost sensitivity?"

That's the R step, performed out loud. Most candidates skip straight to boxes; interviewers notice the ones who ask what the boxes must survive.

Expect the probes: "Assume reasonable NFRs." — then state them, measurably: "I'll assume p99 under 200 ms, 99.9% availability, eventual consistency for analytics, strong for the write path — challenge any of those." You've just demonstrated the vague-to-measurable skill unprompted. "These requirements conflict — now what?" — name the conflict type, pick a winner per situation, and say you'd document the decision (Bonus C's taxonomy, one article early). "What's RTO vs RPO?" — downtime tolerance vs data-loss tolerance, then immediately connect each to a mechanism: failover rehearsals, backup frequency.

The differentiator: connecting each NFR to its mechanism by name — "99.9% means replicas plus health-checked failover; the 100 ms p99 means the redirect path can't afford synchronous analytics." Cause, then effect. That's architecture out loud.

Real-World Engineering Lens

Put an NFR block in the design-doc template — right above Bonus A's estimation block. Per journey: p99, availability, consistency per data type, retention, audit, cost ceiling. Plus one line: the trade-off we chose, and why.

Review NFRs in the same meeting as the design, never as a compliance pass afterward. The code shapes the house; it can't be inspected into it.

Interrogate every vague word. "Scalable" — to what QPS? "Secure" — which audit obligations, what rotation cadence? The question takes ten seconds; the ambiguity costs quarters.

Reconcile NFRs against dashboards quarterly. Part 12 now knows the real p99, the real availability, the real cost. Update the requirements, or the architecture, whichever one turned out to be fiction.

What's Next

We can measure the forces. We've admitted they fight. Next: learning to tell which kind of fight you're in, because the resolution depends on it.

Bonus C — Architectural Trade-off Types: Physics, Business, and Team Maturity. Some trade-offs are laws you obey, some are choices the business makes, and some are honest admissions about your team. Confusing them is how meetings go in circles. Then Bonus H (polyglot persistence), and then Blog 13 finally draws the boxes.

Question for Readers

Pick one user journey you own — checkout, upload, search, anything.

Can you state, with numbers: its p99 target, its availability promise, what may be stale and for how long, and its monthly cost ceiling?

Every blank you can't fill is an architecture decision currently being made by accident.