Functional vs Non-Functional Requirements
Every system design exercise, whether in an interview or in real product development, starts with gathering requirements, and those requirements fall into two categories that pull architecture in different directions. Functional requirements describe what the system must do — the concrete features and behaviors a user or client can observe, such as 'users can post a tweet' or 'the system returns search results for a query.' Non-functional requirements (NFRs) describe how well the system must do it — qualities like latency, availability, consistency, durability, and cost that are invisible in a feature list but dominate the actual architecture. Two systems with identical functional requirements (e.g., a chat app) can have wildly different architectures depending on their NFRs (e.g., must messages be delivered in order, must they survive a data-center failure, what's the acceptable p99 latency).
Cricket analogy: Like two teams both 'able to score runs and take wickets' (functional) but one plays Test cricket judged on endurance over five days while the other plays T20 judged on strike rate per ball (non-functional) — identical functional goals, wildly different demands.
Capturing Functional Requirements
Functional requirements should be scoped explicitly and narrowly, especially in an interview: rather than designing 'all of Twitter,' a candidate should list the 3-5 core user-facing actions actually in scope — post a tweet, follow a user, view a home timeline — and explicitly state what is out of scope (e.g., direct messages, ads, analytics). This scoping discipline prevents an interview or a real design document from sprawling into an unbounded surface area, and it gives every subsequent architectural decision a clear justification tied back to a specific feature.
Cricket analogy: Like a coach preparing a team not for 'winning every format of cricket' but explicitly for '3 things: powerplay batting, death-over bowling, and fielding drills,' leaving spin strategy and Test technique explicitly out of scope for this camp.
Capturing Non-Functional Requirements
NFRs are typically expressed as measurable targets: availability (e.g., 99.99% uptime, translating to about 52 minutes of downtime per year), latency (e.g., p99 read latency under 200ms), scalability (e.g., support 10 million daily active users, 5,000 writes per second at peak), consistency (e.g., eventual consistency is acceptable for a like counter, but strong consistency is required for a bank balance), and durability (e.g., no data loss once a write is acknowledged). Because NFRs are the primary driver of architecture — a strong-consistency requirement rules out certain caching strategies, and a low-latency global requirement forces multi-region deployment — a design that skips NFR gathering usually produces an architecture that is either wildly over-provisioned or quietly broken under real load.
Cricket analogy: Like a stadium's ticketing system targeting 99.99% uptime during a World Cup final (about 52 minutes of downtime a year), sub-200ms seat-map loading, support for a sold-out 100,000-seat rush, eventual consistency for a 'seats remaining' counter, but strong consistency required for the actual seat assignment.
Functional requirements (WHAT):
- User can shorten a long URL into a short code
- User can be redirected via the short code
- Short codes cannot collide
Non-functional requirements (HOW WELL):
- 100M new short URLs per month
- Read:Write ratio of 100:1 (reads dominate)
- Redirect latency < 100ms at p99
- 99.9% availability
- Eventual consistency acceptable for click-count analyticsNetflix explicitly prioritizes availability over strict consistency for its recommendation and browsing systems — showing a slightly stale row of recommended titles is a far better user experience than an error page, an NFR trade-off codified in their adoption of eventually-consistent data stores for those services.
A frequent interview mistake is diving straight into drawing boxes and arrows before any requirements — functional or non-functional — have been clarified. Without agreed-upon scale numbers and consistency needs, every subsequent design choice is unjustified guesswork, and interviewers will probe exactly this gap.
- Functional requirements define observable behavior (what the system does); non-functional requirements define quality attributes (how well it does it).
- Scoping functional requirements narrowly (in scope vs. explicitly out of scope) keeps a design focused and justifiable.
- Non-functional requirements are usually the true architectural drivers — they determine data store choice, caching strategy, and topology.
- NFRs should be expressed as measurable targets (uptime percentage, p99 latency, requests per second) rather than vague adjectives.
- Different NFR priorities (e.g., availability over consistency) lead to fundamentally different architectures for otherwise similar features.
- Skipping requirement gathering is one of the most common and costly system design mistakes.
Practice what you learned
1. Which of the following is a functional requirement for a URL shortener?
2. Why are non-functional requirements often considered the true drivers of system architecture?
3. What is the benefit of explicitly stating what is 'out of scope' when gathering functional requirements?
4. A system requires strong consistency for financial balances but can tolerate eventual consistency for a 'likes' counter. This distinction is an example of:
5. What is a common and costly mistake in system design related to requirements?
Was this page helpful?
You May Also Like
What Is System Design?
An introduction to the discipline of designing large-scale software systems, covering what system design means, why it matters, and how it differs from low-level coding.
Scalability Fundamentals
Core concepts behind building systems that handle growing load gracefully, including scaling dimensions, bottleneck identification, and the diminishing returns of naive scaling.
The System Design Interview Approach
A structured framework for tackling open-ended system design interview questions, from requirement gathering through high-level design, deep dives, and trade-off discussion.
The CAP Theorem
A foundational result stating that a distributed data store can only guarantee two of consistency, availability, and partition tolerance at once, shaping every distributed database's design.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics