# Non-Functional Requirements
Non-functional requirements define how the system must behave under real operating conditions: latency, throughput, availability, durability, consistency, security, cost, and operability.
The key rule: **make them measurable**.
| Vague | Useful |
|---|---|
| The API should be fast | p95 server latency under 50 ms for read requests |
| The system should scale | 10k writes/sec sustained, 50k writes/sec burst for 5 minutes |
| The app should be reliable | 99.9% monthly availability for the public API |
| Data should be safe | RPO under 5 minutes, RTO under 30 minutes |
| Search should be fresh | 99% of indexed documents visible in search within 30 seconds |
## Why They Shape Architecture
Functional requirements tell you what to build. Non-functional requirements decide **how expensive and complex the design must become**.
```mermaid
flowchart LR
NFR[Non-functional target] --> Choices[Architecture choices]
Choices --> Cost[Cost]
Choices --> Complexity[Complexity]
Choices --> Ops[Operational burden]
```
For example:
- Strong consistency may rule out async replication for a critical path.
- Low tail latency may require caching, precomputation, and request hedging.
- High availability may require multi-zone or multi-region design.
- Low cost may favor a monolith and managed services over custom distributed infrastructure.
## From Goal To Target
A useful NFR has a user path, a number, a percentile or window, and a measurement point. "Checkout is fast" is not enough. "Checkout confirmation returns in under 800 ms at p95, measured at the API edge during 2k requests/sec" can drive design.
| Requirement | Metric | Design pressure |
|---|---|---|
| Latency | p50, p95, p99 by endpoint | Caching, query shape, fanout limits |
| Throughput | Sustained and burst requests/sec | Partitioning, queues, backpressure |
| Availability | Monthly uptime by critical path | Redundancy, failover, degraded modes |
| Durability | RPO and accepted data-loss window | Replication, backups, write acknowledgment |
| Consistency | Allowed stale reads or conflicts | Transactions, locks, read models |
| Operability | Detection and recovery time | Observability, runbooks, safe deploys |
| Cost | Budget per tenant, request, or GB | Storage tiering, autoscaling, retention |
## Workload Questions
- What are the read and write rates today, and what is the expected peak?
- Is traffic steady, spiky, seasonal, or driven by launches?
- Which paths are interactive and which can be asynchronous?
- What is the largest tenant, object, fanout, or import?
- Which failures must be invisible, and which can become degraded behavior?
- What compliance, security, or audit constraints remove easy options?
## Example
For a notification system, "send messages" is a functional requirement. Useful NFRs are different:
- 99% of accepted transactional emails are handed to the provider within 10 seconds.
- Marketing campaigns can process 1 million recipients over 4 hours without affecting transactional messages.
- Duplicate delivery is allowed for low-priority digests but not for password reset emails.
- Delivery status is queryable for 30 days, then aggregated for cost control.
Those targets imply queues, priority lanes, idempotency keys, rate limits, and retention rules. Without the numbers, the architecture discussion stays abstract.
## Failure Modes
- Optimizing p50 latency while p99 users suffer from slow dependencies.
- Treating all endpoints as equally important instead of defining critical paths.
- Promising high availability without defining what counts as "available".
- Ignoring operational NFRs until the first incident.
- Designing for imaginary peak traffic while missing current correctness needs.
## Staff-Level Habit
When someone says "fast", ask: **fast for whom, at what percentile, under what load, and measured where?**
Client-perceived latency, API latency, database query time, and background job completion time are different numbers. Mixing them leads to bad designs.
Good NFRs should be revisited. A startup can begin with simpler targets, then raise them as usage, revenue, or regulatory risk grows.