Requirements → NFRs

The customer for this track

Every lesson in this track follows ParcelPath, a fictional parcel-tracking company. Their brief, as written by their CTO:

"We're moving our tracking platform onto Kubernetes in our own two data centres. About 40 services, PostgreSQL, Kafka and Redis. Customers and couriers hit the tracking API all day, with peaks during holiday season. It must be fast, always up, secure, and we can't lose orders. Budget matters."

Your first job is to turn that into something a design can be tested against.

Functional vs non-functional

• Functional: what the system does (track a parcel, create an order).
• Non-functional (NFRs): how well: availability, latency, throughput, scalability, durability, security, operability, cost.

Platform design is mostly about NFRs.

Make every NFR measurable

ID	Category	Requirement	Target	Measured
NFR-01	Availability	Tracking API successful responses	99.95% / 30 days	Ingress logs/metrics, 5xx + timeouts = bad
NFR-02	Latency	GET /track	p99 < 300 ms at ≤ 3,000 req/s	Ingress histogram
NFR-03	Throughput	Peak load (holiday)	3,000 req/s sustained 2 h, 4,500 burst 10 min	Load test
NFR-04	Durability	Orders	RPO 5 min, RTO 60 min	DR drill
NFR-05	Scalability	Growth	2× traffic in 18 months without redesign	Capacity model
NFR-06	Security	Data in transit / at rest	TLS 1.2+ everywhere external; encrypted volumes	Config audit
NFR-07	Operability	Upgrades	Kubernetes minor upgrade without customer-visible downtime	Upgrade test
NFR-08	Cost	Infra budget	≤ agreed hardware envelope (N servers)	Sizing sheet

Ask who owns each target and how it will be measured, before designing anything.

Availability math you'll use

A 30-day month has 43,200 minutes:

Target	Allowed downtime / 30 days
99.9%	43.2 min
99.95%	21.6 min
99.99%	4.32 min

• Serial dependencies multiply: API (99.95%) → database (99.95%) → at best ≈ 99.90%.
• Parallel redundancy helps only if failures are independent: two 99% components give 99.99% on paper, but shared power, network, software bugs or operators break independence.
• Every planned maintenance counts too, unless the SLO explicitly excludes it (it usually shouldn't).

RPO and RTO

• RPO (recovery point objective): the maximum acceptable data loss, in time. RPO 5 min → replication or backups at least every 5 minutes.
• RTO (recovery time objective): the maximum time to restore service. RTO 60 min → failover must be rehearsed and largely automated.
• Set them per data class: orders (strict), tracking events (can be replayed from Kafka?), caches (none).

How do you respond?

Negotiate the architecture, not the number:

• 99.99% allows 4.3 minutes of downtime a month, including upgrades, bad deploys and every incident. Shared power and network in one room are common-cause failures that no amount of Kubernetes replication fixes.
• Show the math and the failure modes: what 99.99% would need (at least two independent failure domains: separate power, network and ideally sites, plus automated failover and very mature operations).
• Offer options: 99.95% on the current footprint with a clear list of risks; or 99.99% with a second site/independent power and the added cost.
• Agree how it's measured (at the ingress, per 30 days) and what's excluded (nothing, ideally).

The outcome is a documented decision (ADR, lesson 05) the customer signs off, not a promise the design can't keep.

Recap

• Turn wishes into measurable NFRs: metric, target, percentile, window, load, measurement point, owner.
• Availability math: minutes per month; serial dependencies multiply; parallel only helps when failures are independent.
• RPO (data loss) and RTO (time to restore) per data class.
• Negotiate architecture and cost when targets exceed the footprint, and write the decision down.