System Design

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:

  1. Scalability: Can the system handle 10,000 users? What about 10 million concurrent active users?
  2. Latency (Performance): How fast does the system respond? (e.g., "The search API must return results in the 99th percentile under 200ms.")
  3. Availability: How much uptime is required? (e.g., "The system needs highly available 99.99% uptime.")
  4. 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)?
  5. 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.