Every good system design starts with requirements.
Before choosing databases, caches, or architectures, you must clearly understand what the system should do and how well it should do it.
These two dimensions are known as functional requirements and non-functional requirements.
Many system design failures — and interview failures — happen because engineers misunderstand or ignore this distinction.
In this blog, you’ll learn:
- What functional and non-functional requirements really mean
- How they differ
- Why non-functional requirements often matter more
- How to use them correctly in system design discussions
What Are Functional Requirements?
Functional requirements describe what the system does.
They define the system’s behavior, features, and capabilities from a user’s perspective.
In simple terms:
Functional requirements describe actions.
Examples of Functional Requirements
For a typical application, functional requirements might include:
- Users can create an account
- Users can log in and log out
- Users can send messages
- Users can upload files
- Users can search content
If a requirement can be written as:
“The system should allow users to…”
It is usually a functional requirement.
What Are Non-Functional Requirements?
Non-functional requirements describe how the system behaves under constraints.
They define quality attributes, not features.
In simple terms:
Non-functional requirements describe system qualities.
Examples of Non-Functional Requirements
Common non-functional requirements include:
- Scalability
- Performance
- Reliability
- Availability
- Security
- Consistency
- Cost constraints
- Maintainability
These requirements apply across the entire system, not to a single feature.
Key Difference Between Functional and Non-Functional Requirements
Functional requirements define what the system does.
Non-functional requirements define how well the system does it.
Both are equally important, but non-functional requirements often shape the architecture more strongly.
Why Non-Functional Requirements Matter More in System Design
In real-world systems:
- Many systems have similar features
- What differentiates them is quality
For example:
- Many apps allow file uploads
- Few handle millions of uploads reliably
Non-functional requirements influence decisions like:
- Monolith vs microservices
- SQL vs NoSQL
- Strong vs eventual consistency
- Vertical vs horizontal scaling
Ignoring non-functional requirements leads to fragile systems.
Scalability Explained
Scalability is the ability of a system to handle growth.
Growth can be in:
- Number of users
- Number of requests
- Amount of data
A scalable system can grow without major redesign.
Scalability is not about speed — it is about capacity.
Performance Explained
Performance refers to how fast the system responds.
Common performance metrics include:
- Latency (response time)
- Throughput (requests per second)
A system can be:
- Fast but not scalable
- Scalable but slow
Performance and scalability are related, but not the same.
Reliability Explained
Reliability is the ability of a system to function correctly over time, even when failures occur.
A reliable system:
- Handles failures gracefully
- Recovers automatically
- Minimizes data loss
Failures are inevitable. Reliability determines how well you handle them.
Latency vs Throughput
These two terms are frequently confused.
Latency
- Time taken to process a single request
- Measured in milliseconds
Throughput
- Number of requests handled per unit time
- Measured in requests per second
A system can have:
- Low latency but low throughput
- High throughput but higher latency
Both must be balanced based on requirements.
How Requirements Drive Architecture Decisions
Consider a messaging system.
Functional Requirements:
- Users can send messages
- Users can receive messages
- Messages are stored
Non-Functional Requirements:
- Messages should be delivered within 200ms
- System should support millions of users
- System should tolerate server failures
These non-functional requirements will push you toward:
- Horizontal scaling
- Message queues
- Replication
- Eventual consistency
The architecture emerges from requirements, not the other way around.
How to Identify Requirements in an Interview
In system design interviews, requirements are rarely given clearly.
You must extract them.
Ask questions like:
- What scale are we targeting?
- What latency is acceptable?
- Is consistency critical?
- What happens during failures?
- Are there cost constraints?
Interviewers expect this clarification.
Common Mistakes Engineers Make
- Treating non-functional requirements as optional
- Assuming scalability without confirmation
- Ignoring failure scenarios
- Designing features before clarifying constraints
Avoiding these mistakes instantly improves your design quality.
A Simple Mental Model
Use this mental checklist:
- What features must exist?
- What scale must the system handle?
- How fast must it respond?
- How reliable must it be?
- What trade-offs are acceptable?
This keeps your design grounded.
Key Takeaways
- Functional requirements define system behavior
- Non-functional requirements define system quality
- Non-functional requirements heavily influence architecture
- Scalability, performance, and reliability are distinct concepts
- Always clarify requirements before designing
What’s Next?
In the next blog, we’ll cover:
👉 Scaling Basics & Estimation
You’ll learn how to think about growth, capacity, and back-of-the-envelope calculations.
