What the system does vs how well it does it.
Functional vs Non-Functional Requirements: what the system does vs how well it does it
frame the problem before drawing the system
Tighter latency targets push compute and data to the edge.
Functional requirements answer 'what does the system do?' — sign up, post a tweet, search products. Non-functional requirements answer 'how well does it do them?' — at what latency, at what scale, with what availability, at what cost. Most architectural decisions are driven by NFRs, not FRs.
FRs are usually easy to list and look like product specs. NFRs are easy to wave away with words like 'fast' and 'reliable' that mean nothing in design. The job is to turn each NFR into a number: p95 < 200ms, 99.9% monthly availability, 10k QPS sustained at peak.
NFRs frequently collide with each other. Strong consistency fights low latency. High availability fights cost. Encryption everywhere fights debuggability. Ranking NFRs is a product decision; making the tradeoff visible is an engineering one.
Some NFRs are architecturally load-bearing: a 99.99% target almost forces multi-region active-active; sub-50ms global p95 forces edge compute; sub-cent unit cost forces aggressive caching and shared infrastructure.
Spec says 'a fast, reliable checkout that scales globally.'