Functional vs Non-Functional Requirements | System Design Essentials
Functional vs Non-Functional Requirements
The very first step in any system design interview—and any real-world engineering project—is gathering requirements. Before you draw a single box, choose a database, or write a line of code, you must understand exactly what the system needs to do and how well it needs to do it.
Requirements are split into two distinct categories: Functional Requirements and Non-Functional Requirements (NFRs).
Functional Requirements: The "What"
Functional requirements define what the system should do. They describe the specific behaviors, features, API endpoints, and business logic that the end-user expects.
If a system fails to meet a functional requirement, it is fundamentally broken or incomplete from the user's perspective.
Examples of Functional Requirements:
- Twitter: Users should be able to post a tweet. Users should be able to follow other users.
- Uber: Riders should be able to request a ride. Drivers should be able to accept a ride.
- E-commerce: Users must be able to add items to a shopping cart and process payments securely.
Code Example: Defining Functional APIs
In a design document, Functional Requirements translate directly into your API contracts. Exploring them early helps you define the data structures.
// Functional Requirement 1: Users can post a tweet.
POST /v1/tweets
interface CreateTweetRequest {
userId: string;
content: string; // max 280 chars
mediaUrls?: string[];
}
// Functional Requirement 2: Users can follow others.
POST /v1/users/{userId}/follow
interface FollowUserRequest {
targetUserId: string;
}
Non-Functional Requirements (NFRs): The "How"
Non-functional requirements specify how the system should perform. They define the system's quality attributes, constraints, and operational characteristics.
While functional requirements dictate the APIs, NFRs dictate the architecture. In a system design interview, this is where you showcase your engineering depth.
Key Categories of NFRs:
- Scalability: Can the system handle 10,000 users? What about 10 million concurrent active users?
- Latency (Performance): How fast does the system respond? (e.g., "The search API must return results in the 99th percentile under 200ms.")
- Availability: How much uptime is required? (e.g., "The system needs highly available 99.99% uptime.")
- Consistency vs. Availability (CAP Theorem): If a network partition occurs, do we favor showing the most up-to-date data (Consistency) or ensuring the system remains responsive (Availability)?
- Security & Compliance: How is user data encrypted at rest and in transit? Does the system need to comply with GDPR or HIPAA?
Balancing the Two: The Architectural Impact
To see how NFRs drastically change your architecture, let's look at a simple feature: "Users can upload videos."
Scenario A: Internal Company Tool
- Functional: Users can upload videos.
- Non-Functional: Only 100 internal employees use it. It's okay if uploads take a few minutes. If it goes down for an hour, it's fine.
Architecture: A simple monolith Next.js app saving files directly to a single AWS S3 bucket.
Scenario B: YouTube
- Functional: Users can upload videos.
- Non-Functional: The system must support 100,000 video uploads per second globally with exactly zero downtime, generating 5 different resolutions per video within 30 seconds.
Architecture:
[ Client ] -> [ Global Load Balancer ] -> [ Upload Microservices (Autoscaled) ]
|
[ Distributed Message Queue (Kafka) ]
|
[ Video Transcoding Workers ]
|
+------------------+------------------+
| |
[ Video Metadata DB ] [ CDN / Object Storage ]
Notice how the Functional Requirement remained exactly the same, but the Non-Functional Requirements forced us to introduce Load Balancers, Kafka Queues, Worker Nodes, and Content Delivery Networks (CDNs).
Always clarify both before designing your system! Watch the video above for a deeper dive into requirement gathering strategies.