Stop Saying Your System Is "Fast and Scalable." That Is Not a Requirement.

Watch the 40-second version on YouTube

Every system design interview has a moment where the candidate says the system should be "fast and scalable," and the interviewer's eyes glaze over. That is not a requirement. That is a wish. Wishes do not pick architectures. Numbers do.

Here is the split that matters. Functional requirements are what the system does: login, search, checkout, upload a profile photo. Every candidate gets these right, and they are nearly useless, because two systems with identical features can need completely different architectures.

Non-functional requirements are how well the system must do it: latency, throughput, availability, consistency, data scale. Name these first, because they pick your architecture for you. "Fast" at 50ms p95 is a CDN, edge caching, and a read path with no cross-region calls. "Fast" at 2 seconds p95 is a plain server and a nap. Same word, different system, different budget, different on-call pain.

The non-obvious part: non-functionals are the interviewer's scoring rubric wearing a costume. Every "trade-off" discussion they steer you toward is a non-functional you never wrote down. Strong versus eventual consistency is not a philosophy question, it is a latency number and a conflict-resolution budget. Caching strategy is not a vibe, it is your read-to-write ratio. When you quantify, the design stops being a drawing exercise and starts being arithmetic, and arithmetic is much harder to argue with.

This is not interview theater either. Real production outages are almost never "the feature was wrong." They are "nobody wrote down the number," followed by a database melting at 3 a.m. because someone assumed 100 requests a second meant 100,000.

So steal this. Before you draw a single box, in an interview or a real design doc, fill in the five lines. It takes 30 seconds and it is the highest-ROI 30 seconds in architecture.

REQUIREMENTS, QUANTIFIED (the 30-second script)
[ ] Latency:      p95 ___ ms, p99 ___ ms (which endpoints? reads vs writes?)
[ ] Throughput:   ___ reads/s, ___ writes/s, peak multiplier ___x
[ ] Scale:        ___ DAU, ___ total records, growth ___x per year
[ ] Availability: ___% (two nines = 87h downtime/yr, three nines = 8.8h)
[ ] Consistency:  strong / eventual / last-write-wins (pick one, defend it)

If a line stays blank, say so out loud and state your assumption. Interviewers score that too. It beats "fast and scalable" every single time.

Question 6 of 60 in the Frontend System Design Interview Playbook. What is the worst unquantified requirement you have ever seen in an interview? I am collecting them.