Hello! Welcome back to your course on backend engineering.
In our last lesson, we compared monolithic and microservice architectures. We saw that critical decisions, like which architecture to choose, are driven by factors like scalability, maintainability, and team structure. These factors aren't features you can see; they are qualities of the system.
Today, we'll formalize the process of identifying and analyzing these driving factors. This is the first and most critical step in any system design process. Before writing a single line of code or choosing a database, you must understand the problem you're solving. This lesson covers how to analyze the functional and non-functional requirements for a given system design problem.
Getting this step right is the difference between building a system that works in theory and one that succeeds in the real world. By the end of this lesson, you'll have a structured framework for dissecting any system design problem, defining its goals, and laying the groundwork for a robust architecture.
1. Functional vs. Non-Functional Requirements: The Core Distinction
Every system design discussion begins with separating requirements into two fundamental categories: what the system does, and how well it does it.
-
Functional Requirements describe the system's specific behaviors or features. They answer the question, "What must the system do?" For example, "A user must be able to upload a profile picture." These are often captured as user stories or use cases.
-
Non-Functional Requirements (NFRs) describe the quality attributes or constraints of the system. They answer the question, "How well must the system do it?" For example, "The profile picture upload must complete within 2 seconds." These are the primary drivers of your architectural decisions.
Let's ground this with a clear definition and some examples.
Functional vs Non Functional Requirements
The article 'Functional vs Non Functional Requirements' from the System Design Handbook provides a crisp, practical distinction between these two types of requirements. It's essential reading to establish our core vocabulary.
Read the first section, 'The core distinction, without making it academic'. Pay close attention to the table comparing functional and non-functional requirements for different systems (URL shortener, chat, etc.).
To visualize this distinction, here is a helpful comparison table:
A common way to document and visualize functional requirements is through a Use Case Diagram. This diagram shows the interactions between users (called "actors") and the system's main functions.
2. The Process: How to Elicit Requirements
You won't simply be given a neat list of requirements. A crucial skill is knowing how to ask the right questions to uncover them. This is an active process of clarification, prioritization, and quantification.
Let's watch a short video that outlines the first step of a standard system design framework, which is all about understanding the problem and defining requirements.
How to Answer System Design Interview Questions (Complete Guide)
This video from Exponent, although framed for interviews, provides an excellent overview of the initial problem-solving phase that is universally applicable in real-world system design.
Watch the section 'Step 1: Define the Problem Space' (01:15 - 03:18). Focus on the types of clarifying questions you should ask to define the scope and identify both functional and non-functional requirements.
The video introduces a systematic approach. The System Design Handbook article we read earlier formalizes this into a "state machine" that provides a reliable workflow.
Functional vs Non Functional Requirements
Let's return to the 'Functional vs Non Functional Requirements' article to look at a structured process for gathering requirements.
Read the sections 'Requirements state machine for interviews' and 'How to ask requirement questions like an interviewer'. The table of questions in the second section is particularly valuable as a practical script you can use to start any design discussion.
To summarize this crucial process:
- Clarify: Define the users and core actions to establish a tight scope.
- Prioritize: Identify the most critical features and quality attributes. You can't optimize for everything.
- Quantify: Convert vague goals like "fast" or "reliable" into concrete, measurable numbers.
Asking structured questions about users, actions, scale, and constraints is the key to unlocking the information needed for these steps.
3. A Deep Dive into Non-Functional Requirements
While functional requirements define the product, non-functional requirements define the architecture. Getting them right is what makes a system robust, scalable, and maintainable.
There are many categories of NFRs. This next video provides a fantastic, detailed walkthrough of the most important ones, using a mind-map to organize the concepts.
Non-Functional Requirements - FULL guide with REAL Examples
The video 'Non-Functional Requirements - FULL guide with REAL Examples' from Win The Cloud 🙌🏻 offers a comprehensive exploration of key NFRs. The presenter's mind-map approach helps visualize how different quality attributes relate to each other.
This is a detailed video, so focus on these specific segments to get a strong overview: Introduction (00:00 - 04:06): Understand what NFRs are and see the initial mind-map structure (Reliability, Usability, Performance, Cost, etc.). Reliability Deep Dive (04:06 - 12:55): This is the most detailed section. Pay close attention to the breakdown of Availability (SLAs), Fault Tolerance (resilience, retries, replication), and Disaster Recovery. This is core backend knowledge. Cost (15:10 - 18:21): This section connects technical decisions to business realities like user projections and development costs. Maintainability (18:21 - 21:05): This ties directly back to our last lesson on monoliths vs. microservices, discussing modularity, decoupled services, and testability.
Here's a concise list of the most critical NFRs, drawing from the video and other resources:
- Performance & Latency: How fast is the system? Often measured in response time (e.g., p95 or p99 latency).
- Scalability & Throughput: How does the system handle growth? Measured in requests per second (QPS) or users.
- Availability: How often is the system operational? Measured as a percentage of uptime (e.g., 99.9% "three nines").
- Reliability & Durability: Does the system behave correctly and avoid data loss? Involves concepts like retries, idempotency, and write-ahead logs.
- Consistency: How up-to-date is the data that users see? (e.g., strong vs. eventual consistency).
- Security: How does the system protect against threats? Involves authentication, authorization, and encryption.
- Maintainability & Operability: How easy is it to debug, update, and operate the system? Involves modularity, logging, and monitoring.
The Power of Quantification
The most important step in analyzing NFRs is to quantify them. A vague goal is not a requirement. It must be a measurable target that you can design for and later verify.
Functional vs Non Functional Requirements
Let's revisit our 'Functional vs Non Functional Requirements' article one last time to focus on this critical step.
Read the section 'Turning non-functional requirements into numbers'. The table here is invaluable, as it shows how to convert a concept like 'Latency' into a measurable target like 'p95 < 200 ms' and identify the trade-offs.
4. From Requirements to Architecture
The ultimate goal of this analysis is to justify your design choices. Every major architectural component should map back to a specific requirement.
Functional vs Non Functional Requirements
To see this connection in action, let's look at the final part of the same article.
Quickly read through these last three sections: 'Requirements that change the architecture' 'Requirements-to-design mapping: turn statements into components' 'Walkthrough 1: "Design a URL shortener" requirements to design' Notice how a requirement like 'Read-heavy load' directly leads to an architectural change like 'Cache hot reads'. The URL shortener example is a perfect, simple illustration of the entire process.
Let's summarize the URL shortener example:
- Functional Requirements:
- Create a short link from a long URL.
- Redirect from a short link to the original URL.
- Non-Functional Requirements (Quantified):
- Latency: Redirects must be fast (e.g., p95 < 100ms).
- Availability: The service must be highly available (e.g., 99.9% uptime).
- Read/Write Mix: The system will be very read-heavy (~100 reads for every 1 write).
- Architectural Implications:
- The low latency and read-heavy NFRs strongly justify using a cache in front of the database for the redirect path.
- The high availability NFR justifies having multiple server instances and database replication.
This clear line from requirement to component is the hallmark of intentional, defensible system design.
Conclusion
Today we established the foundational process for all system design. By systematically analyzing requirements, you move from a vague problem statement to a concrete set of goals that will guide every subsequent architectural decision.
Key Takeaways:
- Functional requirements define what a system does (features), while non-functional requirements define how well it does it (quality attributes).
- NFRs like latency, scalability, and availability are the primary drivers of backend architecture.
- Requirement analysis is a structured process: Clarify scope, Prioritize goals, and Quantify quality attributes into measurable targets (SLOs).
- Every major architectural decision (e.g., adding a cache, a queue, or a replica) should be a direct response to a specific, quantified requirement.
Preview of the Next Lesson
In our URL shortener example, the non-functional requirement for high availability led to the decision to use multiple server instances. But once you have multiple instances, a new question arises: how do you distribute incoming traffic among them?
In our next lesson, we will explore the answer: load balancers. We will explain how they work to improve both availability and scalability and compare the common algorithms they use to distribute traffic.