Non-functional requirements

Purpose

Use this article before drawing architecture boxes. It turns vague goals such as “fast,” “reliable,” or “scalable” into measurable constraints tied to specific operations, then uses those constraints to justify design choices.

TL;DR

• Non-functional requirements (NFRs) drive architecture more than features do. The same feature ("user views their feed") produces completely different systems depending on the latency, consistency, and availability targets.
• The 6 core NFRs to clarify in most interviews: Availability, Latency, Throughput, Consistency, Durability, and Scalability. These cover many architecture-driving constraints, but domain-specific requirements may add more.
• Every NFR needs a quantified target or an explicit assumption. "High availability" is vague. "99.99% availability" gives you a target against which to evaluate redundancy and failure handling.
• NFRs trade off against each other. Trying to maximize 99.999% availability, strong consistency, and sub-10ms latency at the same time is generally incompatible under common distributed-system failure and network assumptions. Good design states which constraints are prioritized.
• Use the NFR sentence template to anchor your design: "We need X availability with Y latency for Z throughput, accepting [consistency model] for [data type]."

---

Mental Model

An NFR is a measurable constraint on a particular operation under a stated workload and failure model. For each important operation, ask:

• What is the target? A percentile latency, availability window, throughput rate, freshness bound, or data-loss budget.
• Where does it apply? A read path, write path, background job, region, tenant, or critical data type.
• What does it force? Caching, replication, batching, partitioning, queueing, local processing, or a simpler scope.
• What does it cost? More coordination, stale reads, storage, operational work, or reduced availability during a failure.

Quantify only the numbers that change the architecture. Mark estimates as assumptions and revisit them when the product or workload changes.

---

Same Feature, Two Completely Different Architectures

Consider this functional requirement: "Users can view a product's current price."

For an internal analytics dashboard with 50 users, this is a SQL query against a single PostgreSQL instance. Response time of 500ms is fine. If the database is down for 10 minutes during a deploy, nobody panics.

For a global retail product page with hundreds of millions of monthly visitors, this might be a globally replicated cache layer backed by a distributed database, served from CDN edge locations, with a sub-50ms P99 target, a 99.99% availability target, and capacity for hundreds of thousands of reads per second during a peak event.

Same feature. Same functional requirement. Completely different systems. The difference? Non-functional requirements.

A common weak answer designs an entire architecture without asking about latency, availability, or consistency targets. The architecture may look reasonable in isolation, but its choices are hard to evaluate because the constraints are unstated. Was that Redis cache there for latency reasons? For throughput? The answer should say.

NFRs are the bridge between "what the system does" and "how the system is built." Without them, your architecture decisions are arbitrary.

---

The 6 NFRs That Commonly Drive Architecture

These are six common non-functional requirements. For each one, the article covers what it means, illustrative thresholds, the architecture changes it may motivate, and how to phrase the question in an interview.

1. Availability

Availability is the percentage of time the system is operational and serving requests correctly. It's expressed as "nines."

Concrete thresholds:

These rows are heuristics, not guarantees. The achievable availability depends on the service boundary, dependency behavior, maintenance policy, and how the target is measured.

What it forces in your architecture:

For a 99.99% target, each component on the critical path needs redundancy or a documented failover story. That often rules out a single database, load balancer, or cache node and motivates multi-AZ deployments, read replicas, Sentinel/Cluster Redis, and health-check-driven routing.

A 99.999% target may push you toward multi-region or other carefully engineered failure isolation, which introduces consistency challenges (data written in one region takes time to reach another).

How to ask in an interview:

"What availability target should I design for? Is this a 99.9% SLA (internal tool level) or 99.99% (user-facing product level)?"

Saying "high availability" without a number leaves the design underspecified. Saying "99.99% availability" and then discussing multi-AZ failover makes the target and its cost explicit.

2. Latency

Latency is the time between a user's request and the system's response. Always talk in percentiles, not averages.

Concrete thresholds:

What it forces in your architecture:

Sub-50ms P99 leaves little room for a slow cache miss or a cross-region round trip. It often motivates a cache-first read path with a measured high hit rate and data placed near the caller; whether it is sufficient depends on the actual latency budget.

Sub-200ms is a common target for user-facing APIs. It may allow only a few sequential I/O operations, so careful service decomposition matters: every additional service hop consumes part of the latency budget.

How to ask in an interview:

"What's the acceptable response time for this operation? Should I target sub-100ms (aggressive, cache-first) or is 200-500ms acceptable?"

3. Throughput

Throughput is the volume of requests the system handles per unit of time. Usually expressed as requests per second (RPS) or events per second.

Concrete thresholds:

What it forces in your architecture:

At 100 RPS, a simple architecture is often sufficient. At 10K RPS, you may need horizontal scaling of the app tier and a caching layer that absorbs a large fraction of reads. At 100K+ RPS, consider CDN offloading for static content, partitioning or sharding if the write path requires it, and event streaming (Kafka) when decoupling write-heavy work helps.

The key insight: throughput requirements determine whether you need horizontal scaling and at which layer.

How to ask in an interview:

"What's the expected peak request volume? Should I design for thousands of RPS (moderate scale) or hundreds of thousands (extreme scale)?"

4. Consistency

Consistency determines how fresh the data must be when a user reads it. This is the NFR that most directly constrains your database and replication choices.

The spectrum:

What it forces in your architecture:

Strong consistency often means a single-writer primary for that data, synchronous replication (or consensus like Raft), and bypassing or carefully validating caches for mutable data. It makes multi-region active-active harder for that data path because writes need coordination.

Eventual consistency can enable read replicas, async replication, caching with TTLs, and multi-region deployments. Many high-availability, low-latency architectures use it for at least some data paths.

How to ask in an interview:

"Is it acceptable for users to see slightly stale data? For a social feed, a 5-second delay is usually fine. For inventory counts or financial transactions, we'd need strong consistency."

Here's the honest answer most candidates miss: consistency is not a system-wide setting. Different data within the same system has different consistency requirements. Tweets can be eventual. Follower counts can be approximate. But a financial transaction ledger must be strongly consistent.

5. Durability

Durability determines how much data loss is acceptable during failures. This is separate from consistency (durability is about writes surviving failures, consistency is about reads reflecting writes).

The spectrum:

What it forces in your architecture:

For a zero-loss objective, acknowledge only after the write is protected by the required number of durable locations under the stated failure model. For databases, this may mean synchronous replication or Raft consensus. For message queues, this may mean acks=all in Kafka together with an appropriate in-sync replica and retry policy. This adds latency to writes and still needs operational safeguards.

If you can tolerate some loss (analytics events, view counts), you can use async replication, write-behind caches, and single-node writes with periodic snapshots. Much faster, but you accept that a node failure loses recent writes.

How to ask in an interview:

"Can any recent writes be lost in a failure scenario? Financial transactions probably need zero loss. Analytics events or view counts might tolerate losing the last few seconds."

6. Scalability

Scalability is the system's ability to handle growth in users, data, or traffic through manageable incremental changes. It's less about a single number and more about the growth trajectory.

The dimensions:

What it forces in your architecture:

If the system needs to handle 10x growth, each critical component needs a clear scaling path. That may mean stateless app servers behind a load balancer, a shardable database, a distributed cache, or a deliberately protected single-writer path.

If traffic is bursty (flash sales, viral events), you need either pre-scaling (scale up before the event), auto-scaling (react to load), or queue buffering (absorb spikes and process asynchronously).

How to ask in an interview:

"Should I design for current scale or anticipate 10x growth? And is traffic steady or do we expect spikes (events, campaigns, viral content)?"

---

How NFRs Trade Off Against Each Other

NFRs are in tension. Improving one often degrades another. The practical task is choosing which NFRs to optimize and which to relax for each operation.

The key tensions:

Availability vs Consistency (CAP theorem). During a network partition, a distributed operation must choose which behavior to prioritize: reject writes (preserve consistency but reduce availability) or accept writes on both sides (preserve availability but risk inconsistency). The choice is per system and often per operation.

Latency vs Durability. Synchronous replication (for durability) adds latency to every write. Async replication is faster but risks data loss. You're trading write speed for write safety.

Consistency vs Latency. Strong consistency requires coordination (consensus rounds, synchronous replication), and that coordination adds latency. Eventual consistency can let you read from a nearby replica with less coordination, but it may return stale data.

Throughput vs Consistency. Higher throughput often means more replicas and partitions. More replicas can add coordination overhead for strong consistency. At extreme throughput, eventual consistency may be the practical choice for some paths, while critical mutations remain strongly consistent.

State the tensions explicitly in an interview. "I'm choosing eventual consistency here because it lets me pursue the sub-200ms latency target. If we needed strong consistency, we'd need to accept higher latency or reduce the number of replicas."

---

The NFR Sentence Template

After gathering your NFRs, synthesize them into a single sentence that anchors your entire design. This is the sentence you say out loud before drawing your first architecture box.

The template:

"We need [availability target] availability with [latency target] latency for [throughput target] throughput, accepting [consistency model] for [data type], with [durability guarantee] for writes."

Examples:

For a social media timeline:

"We need 99.99% availability with P99 under 200ms for 100K timeline reads/sec, accepting eventual consistency with a 5-second staleness window, with durable writes (no tweet loss once acknowledged)."

For a payment processing system:

"We need 99.99% availability with P99 under 500ms for 10K transactions/sec, requiring strong consistency for account balances, with zero data loss for all financial writes."

For an analytics dashboard:

"We need 99.9% availability with P99 under 2 seconds for 1K queries/sec, accepting eventual consistency with 30-second staleness, tolerating bounded write loss for raw events."

Notice how each sentence can lead to a different architecture. The social media timeline may need a cache-first read path. The payment system may need synchronous replication and consensus. The analytics dashboard can use batch processing and approximate queries.

For your interview: say the NFR sentence out loud before drawing anything. It gives the interviewer a clear rubric to evaluate your architecture against.

---

NFRs Are Per-Operation, Not System-Wide

This is an important design nuance. Applying NFRs uniformly across an entire system is often wasteful or unsafe; different operations can have different NFR profiles.

Example: E-commerce platform

Notice that product browsing and checkout have completely different consistency and durability requirements. Designing both with strong consistency wastes resources. Designing both with eventual consistency risks selling items you don't have.

The right approach: identify the 2 to 3 operations with the most demanding NFRs and design your architecture around those. The less demanding operations can ride on simpler paths.

---

Adapting NFRs and Handling Failure Modes

When a requirement changes, update the affected operation rather than rewriting every target:

• Latency changes: spend the budget across network hops, computation, storage, and retries; then decide whether to cache, pre-compute, colocate, or simplify.
• Availability changes: identify the critical path and its failure domains; add redundancy where it matters and document what degrades.
• Throughput or spike changes: recalculate reads, writes, payload volume, and concurrency; choose horizontal scale, batching, queues, or load shedding.
• Consistency or durability changes: identify which data needs strong reads or protected writes; accept the added coordination and recovery cost only there.

Ask what happens when the cache is cold, a replica is stale, a queue is backed up, a region is unreachable, or a write is retried. A strong NFR statement includes the failure behavior and the acceptable degradation, not only the happy-path number.

---

Common Mistakes

Not quantifying NFRs. "The system should be fast and reliable" is not an NFR specification. Each important NFR needs a number or an explicit bound: P99 under 200ms, 99.99% availability, 50K RPS peak, or a stated qualitative constraint such as "no acknowledged payment loss." Without that anchor, architecture decisions are hard to justify.

Treating all NFRs as equally important. Every NFR has a cost. 99.999% availability can be substantially more expensive and complex than 99.99%. If you design for five-nines availability on an internal dashboard, you're likely over-engineering. Prioritize the NFRs that matter most for the specific use case.

Ignoring NFR tensions. If you claim 99.999% availability, strong consistency, and sub-10ms latency together, the combination may be difficult under the stated network and failure model. Acknowledge the tension and explain your choice.

Applying NFRs system-wide. As discussed above, different operations need different NFR profiles. Applying the strictest requirement to every operation wastes resources and adds unnecessary complexity.

Not connecting NFRs to architecture decisions. The whole point of NFRs is to justify your design choices. If you say "99.99% availability" but then draw a single-node database, there's a disconnect. Every NFR should map to at least one architecture decision.

Forgetting scalability direction. "It needs to scale" means nothing. Scale what? Reads? Writes? Storage? Users? Each dimension has different solutions. A read-scaling problem (add replicas, caching) is fundamentally different from a write-scaling problem (sharding, partitioning).

---

How This Shows Up in Interviews

NFRs are often surfaced early in a system design interview. The useful signal is whether you ask about constraints before designing and connect those constraints to architecture decisions.

What interviewers evaluate:

Common follow-up questions from interviewers:

---

---

30-Second Explanation

“NFRs are measurable constraints that turn a feature into an architecture. I ask for availability, latency, throughput, consistency, durability, and growth assumptions, but I attach each one to a specific operation. Then I map the targets to components and state the trade-offs—for example, accepting stale feed reads to meet a latency target while keeping payment writes strongly consistent and durable.”

5-Minute Explanation

1. Name the critical operations, such as browse, create, update, checkout, or background processing.
2. Quantify the important targets: availability, P50/P99 latency, peak throughput, data growth, freshness, and acceptable loss.
3. Separate steady state from spikes and separate reads from writes.
4. Map each target to an architectural consequence: cache or pre-compute for latency, replicas or partitioning for reads, queues or batching for bursts, and durable replication for critical writes.
5. Write the NFR sentence, then test it against failure modes: stale replicas, cache failure, queue backlog, region loss, and retries.

The result is a small, operation-specific design rubric—not a promise that every target can be maximized at once.

---

Quick Recap

1. NFRs drive architecture more than features do. The same feature produces completely different architectures depending on latency, consistency, and availability targets.
2. The 6 core NFRs to clarify in every interview: Availability, Latency, Throughput, Consistency, Durability, and Scalability. Quantify each one.
3. NFRs trade off against each other. You cannot simultaneously maximize availability, consistency, and latency. Senior designers choose which to optimize and state the tradeoff explicitly.
4. Use the NFR sentence template before designing: "We need X availability with Y latency for Z throughput, accepting [consistency model]."
5. NFRs are per-operation, not system-wide. Different operations within the same system have different availability, latency, and consistency requirements.
6. Connect every NFR to at least one architecture decision. "Redis because P99 < 50ms." "Multi-AZ because 99.99% availability." "Async replication because eventual consistency is acceptable."
7. State NFR tensions before making choices. "There's a tension between latency and durability here. I'm choosing async replication for speed, accepting bounded data loss of up to 5 seconds."

Related Concepts

• Scoping the problem — identify the operations whose constraints matter.
• Capacity planning — turn throughput, storage, and growth assumptions into sizing decisions.
• SLOs, SLIs, and SLAs — connect targets to how reliability and latency are measured.
• Consistency models — go deeper on freshness and coordination choices.
• Replication — understand the durability, latency, and availability effects of copies.

---