Lesson 3Beginner1h 8mAssessment-backed

Non-Functional Requirements

Learn how latency, throughput, availability, durability, consistency, security, cost, and observability become measurable system design targets.

What you will be able to do

Explain the most important non-functional requirements in practical language.

Turn vague words like fast and reliable into measurable targets.

Understand p95 latency, throughput, availability, durability, and consistency at a beginner level.

Connect NFRs to AWS, GCP, and Azure architecture choices.

Use NFRs to evaluate whether a design is production-ready.

Functional requirements say what the system does. Non-functional requirements say how well the system must do it. In production, these quality targets often decide the architecture more than the feature itself.

Why NFRs Matter

Two systems can support the same feature but require very different designs. A private admin tool that can be slow, a payment service that must be correct, and a live chat product that must feel instant all have different non-functional requirements.

Non-functional requirements dashboard — NFRs convert vague quality goals into measurable engineering targets.

Vague phrase	Better NFR	Why it is better
Fast	p95 API latency below 200 ms for create requests	Names the operation, percentile, and target.
Highly available	99.9% monthly availability for order status reads	Defines the user-facing flow and time window.
Never lose data	Accepted payment events must be durably stored before acknowledgement	Defines when durability is required.
Scalable	Handle 5,000 writes/sec for 30 minutes during campaign peaks	States load and duration.
Secure	Tenant data must be isolated and all privileged actions audited	Connects security to real access rules.

Latency and Percentiles

Latency is how long an operation takes. In system design, average latency is often misleading because users feel the slow requests. That is why teams commonly discuss p95 or p99 latency: the request time below which 95% or 99% of requests complete.

Metric	Beginner meaning	Example
Average latency	Typical time across all requests	Average status read is 80 ms.
p95 latency	95 out of 100 requests are this fast or faster	p95 status read is below 250 ms.
p99 latency	99 out of 100 requests are this fast or faster	p99 status read is below 800 ms.
Tail latency	The slowest slice of user experience	Some users see multi-second delays during cache misses.

Design principle

Do not say the system should be fast. Say which operation should be fast, for whom, at which percentile, under what traffic level.

Availability, Durability, and Recovery

Availability means users can successfully use a system when they need it. Durability means accepted data is not lost. Recovery defines how quickly the system should return after failure and how much data loss is acceptable.

Target	Question it answers	Example
Availability	Can users use it?	Order status reads should be available 99.9% monthly.
Durability	Can accepted data be lost?	Confirmed order transitions must survive process crashes.
RTO	How long can recovery take?	Restore service within 30 minutes after region-level incident.
RPO	How much data loss is acceptable?	At most 1 minute of analytics events may be replayed or delayed.

Scenario: Payment Receipt Service

A payment receipt service receives a payment event, stores the receipt, emails the customer, and exposes receipt history. The feature sounds small, but the NFRs decide the design.

Payment receipt service with different non-functional requirements — A payment system separates immediate correctness from background delivery and reporting.

Part of system	NFR	Architecture implication
Payment event ingestion	Do not acknowledge until receipt event is durably stored	Durable database or log before response.
Receipt read API	p95 below 200 ms for recent receipts	Indexes, cache, and small read model.
Email delivery	Can be delayed, must retry safely	Queue plus idempotent worker.
Audit history	Immutable records for compliance	Append-only records and access logs.
Analytics dashboard	Can lag by minutes	Async pipeline instead of slowing the payment path.

Consistency as an NFR

Consistency is not one universal setting. Ask what must be correct immediately and what can become correct after a short delay. A payment confirmation and a dashboard counter do not need the same consistency.

Data	Consistency need	Reason
Payment receipt	Strong enough to prevent missing confirmed receipts	User trust and compliance.
Unread notification count	Can be eventually consistent	Small delay is acceptable.
Inventory checkout	Must prevent overselling for scarce items	Business correctness.
Analytics chart	Can lag by minutes	Reporting is not on the critical user path.

Cloud Mapping for NFRs

Once NFRs are clear, cloud choices become easier. Managed services can reduce operational load, but they still must satisfy latency, durability, availability, compliance, cost, and team constraints.

NFR pressure	AWS examples	GCP examples	Azure examples
High availability compute	ECS/EKS across AZs, Lambda	Cloud Run/GKE across zones	Container Apps/AKS across zones
Durable relational data	RDS/Aurora Multi-AZ	Cloud SQL HA/Spanner	Azure SQL zone redundancy
Async retryable work	SQS + DLQ	Pub/Sub + dead-letter topic	Service Bus + dead-letter queue
Low-latency cache	ElastiCache	Memorystore	Azure Cache for Redis
Observability	CloudWatch/X-Ray	Cloud Monitoring/Trace	Azure Monitor/Application Insights

NFR Brief Template

For each important user flow, define a small set of measurable quality targets. Avoid trying to make every part of the system perfect.

Flow	Latency	Availability	Durability/consistency	Notes
Create payment receipt	p95 below 300 ms	99.95%	Durable before ack	Critical path.
Send receipt email	Within 2 minutes	99.9%	Retry without duplicates	Async path.
View receipt history	p95 below 250 ms	99.9%	Read-your-own receipt preferred	Indexes/cache may help.
Analytics dashboard	Can lag 5 minutes	99%	Eventually consistent	Do not slow critical path.

Beginner Mistakes

Saying reliable without defining availability, durability, or recovery.
Using average latency when p95 or p99 matters more to users.
Making every operation strongly consistent without asking if the product needs it.
Adding queues and caches before identifying the slow or failure-prone path.
Ignoring cost and team support capacity as real non-functional requirements.

Guided Practice

Practice task

Pick a ride-sharing app. Define one latency target, one durability target, one availability target, one consistency target, and one cost or team constraint.

Sample Answer

NFR	Example answer
Latency	Driver location on the customer map should refresh within 5 seconds for active trips.
Durability	Trip start, trip end, fare, and payment events must not be lost after acknowledgement.
Availability	Customers should be able to view active trip status with 99.9% monthly availability.
Consistency	Fare and payment state must be correct; map location can be eventually consistent.
Cost/team	Use managed queues and databases for launch because the team cannot operate custom distributed infrastructure yet.

Before You Continue

You should be able to turn vague quality words into measurable targets.
You should understand why p95 and p99 latency matter.
You should know the difference between availability and durability.
You should understand that consistency depends on the product flow.
You should be ready to estimate traffic and storage in the next lesson.

Requirements and Constraints

Back-of-the-Envelope Estimation