Functional vs non-functional requirements

Two questions, never one

Before drawing a single box, pin down two different things:

• Functional requirements — what the system does. The features and behaviors. “A user can shorten a URL and be redirected to the original.”
• Non-functional requirements (NFRs) — how well it must do them. The qualities: latency, availability, scale, durability, consistency, cost.

Candidates who only chase functional requirements end up designing a correct toy. The NFRs are what make it a systems problem — they’re why you need sharding, caching, replication, and queues at all.

Nailing functional requirements

Take the vague prompt and turn it into a short, explicit feature list, then scope ruthlessly. For “design Twitter” you might list: post a tweet, follow users, view a home timeline, like/reply. Then say out loud: “I’ll focus on posting and the home timeline; I’ll treat search and DMs as out of scope unless you’d like me to cover them.”

Scoping is a positive signal — it shows you can prioritize. Always confirm the cut with the interviewer.

The non-functional requirements that matter

Pick the few that actually shape this design:

• Scale — users, requests/sec, data volume, read:write ratio. Drives partitioning and caching.
• Latency — target response time (e.g. p99 < 200 ms). Drives caching, CDNs, precomputation.
• Availability — uptime target (99.9% vs 99.999%). Drives redundancy and failover.
• Consistency — must reads see the latest write, or is slightly stale OK? Drives the data store and replication model (see “Strong vs eventual consistency” in Chapter 3).
• Durability — can you ever lose committed data? Drives replication and backups.

State a target for each that’s relevant, and ignore the ones that aren’t. “This is read-heavy, latency-sensitive, and can tolerate eventual consistency” already tells the interviewer how you’ll build it.

The tension you’ll keep hitting

NFRs fight each other, and naming the fight is the whole game:

• Strong consistency vs low latency and high availability (the CAP and PACELC theorems, covered in Chapter 2).
• Low latency vs low cost (more caches and replicas cost more).
• High availability vs simplicity (every replica and failover path adds moving parts).

There’s no universally right answer — only the right answer for the stated requirements. That’s why you lock the requirements down first: they’re the yardstick you’ll measure every later decision against.