Back to System design
Functional vs Non-Functional Requirements
easyThe first five minutes of a system design interview decide the next forty, and the mistake that costs most candidates is treating requirements as a formality to get past rather than the constraints that make the design decidable.
Key Concepts
1
Functional requirements are what the system does. Users post messages. Followers see them. Search
returns results. They are testable statements about behaviour, and in an interview you should pin down two
or three rather than enumerating everything the product could do.
Functional requirements are what the system does.
2
Non-functional requirements are what make the design hard. How many users, at what latency, with what
consistency, at what availability, for how much money. "Users can post a message" tells you almost nothing;
"400 million posts a day, timeline loads under 200 ms, a post may take seconds to appear in followers'
timelines" determines fan-out strategy, storage, caching and replication.
Non-functional requirements are what make the design hard.
3
Ask what is out of scope, explicitly. A system design question is deliberately too large for the time
available. Saying "I'll design the posting and timeline path, and treat search, ads and moderation as out
of scope unless you want them" is a scoping decision, and interviewers score it. Candidates who try to
cover everything cover nothing at depth.
Ask what is out of scope, explicitly.
4
Turn every vague adjective into a number. "Fast" is not a requirement; "p99 under 200 ms" is. "Highly
available" is not; "99.9%, which is 43 minutes of downtime a month" is. "Scalable" is not; "10x current
load without a redesign" is. Do this in the room and the design becomes decidable.
Turn every vague adjective into a number.
5
Availability numbers are worth knowing cold, because they sound similar and mean very different
engineering. 99% is 3.65 days of downtime a year. 99.9% is 8.8 hours. 99.99% is 53 minutes, and it rules out
any procedure that needs a human to wake up and log in.
Availability numbers are worth knowing cold
6
Consistency is the requirement people skip, and it drives everything. Ask whether a user must see their
own write immediately, whether two users must see the same value at the same instant, and what a stale read
actually costs. A follower count may be seconds stale; an account balance may not.
Consistency is the requirement people skip, and it drives everything.
7
Write them where both of you can see them, and refer back. A design justified by a requirement you
agreed at minute three is much harder to argue with than one justified by preference.
Write them where both of you can see them, and refer back.
8
What the interviewer is probing.
What the interviewer is probing.
9
1. "What is the difference?" Probing: the fundamentals. Stalls: "One is optional." *Moves
up:* functional is what the system does; non-functional is how well — latency, availability, scale,
durability, security.
1. "What is the difference?"
10
2. "Which should you establish first and why?" Probing: the method. Stalls: "Functional."
Moves up: functional to bound the scope, then non-functional immediately, because scale and
latency targets are what actually shape the architecture.
2. "Which should you establish first and why?"
11
3. "What non-functional questions would you ask?" Probing: whether you know what to ask for.
Stalls: "How many users?" Moves up: daily active users, read-to-write ratio, acceptable latency,
availability target, data retention, and consistency requirements.
3. "What non-functional questions would you ask?"
12
4. "What happens if you skip them?" Probing: the consequence. Stalls: "Nothing." Moves up:
you design for the wrong scale — a system for a thousand users looks nothing like one for a hundred
million, and the interviewer cannot tell which you meant.
4. "What happens if you skip them?"
Turning vague into decidable
Vague Decidable Decides
-------------------------------------------------------------------
"fast" p99 < 200 ms caching, replica
placement, whether
a cross-region hop
is possible at all "scalable" 10x load with no sharding now vs
redesign; 400M later, stateless
posts/day today services "highly available" 99.9% (43 min/month) failover automation,
multi-AZ, on-call
expectations "consistent" read-your-own-writes; quorum settings,
others within 5 s replica routing,
session pinning "secure" PII encrypted at rest; key management,
audit log of access schema, logging
policy "cheap" under X per million cache aggressiveness,
requests storage tiering,
retention policy The habit
When the interviewer uses an adjective, ask for the number. When
they say "you decide", pick one, say it out loud, and design to
it. Either way the requirement becomes something you can point
at later.Availability, in real time
99% 3.65 days/year 87.6 hours 7.2 hours/month 99.9% 8.76 hours/year 43.8 min/month 99.95% 4.38 hours/year 21.9 min/month 99.99% 52.6 min/year 4.4 min/month 99.999% 5.26 min/year 26 s/month
What each tier implies in practice
99% a manual restart during office hours is survivable
99.9% automated failover; a paged human can still be the
recovery path for rarer faults
99.99% no human in the recovery path for common faults;
multi-AZ, automated failover measured in seconds
99.999% multi-region active-active, and the deploy pipeline
itself becomes a reliability risk Composition is the part people miss
Services in series MULTIPLY their availability:
three 99.9% dependencies in a request path
0.999 x 0.999 x 0.999 = 99.7%
= 26 hours/year
-> "our service is 99.9%" is only true if every dependency on
the critical path is better than that, or you degrade
gracefully when one is down. The useful question to ask in the room
"What is the cost of a minute of downtime here?" The answer
tells you which tier is being bought, and it is usually lower
than the candidate assumes.