Functional vs Non-Functional Requirements

6 min read

In a Nutshell

When someone says "design Twitter," there are really two questions hiding inside that prompt. Functional requirements answer "what does the system do?" — things like posting tweets, following users, and viewing a timeline. Non-functional requirements answer "how well does it do it?" — things like 99.99% uptime, page loads under 200ms, and supporting 500 million daily users.

Functional requirements shape your API and data model. Non-functional requirements shape your architecture. A system serving 100 requests per second and one serving 100,000 are fundamentally different systems — even if they do the exact same thing.

2D minimalistic diagram showing two columns: left column labeled Functional with icons for features like post, follow, search; right column labeled Non-Functional with icons for speed, uptime, scale — connected by arrows to a central system box

How It Actually Works

Functional Requirements

These describe the user-visible capabilities of the system. Think of them as the features list — what a user can do.

To identify them, ask:

Who are the users? (end users, admins, other services)
What actions can each user perform?
What data goes in and what comes out?

Examples for a social media platform:

A user can create a post with text and images
A user can follow/unfollow other users
A user can view a chronological feed of posts from people they follow
A user can search for other users by name

Each functional requirement typically maps to one or more API endpoints and database tables. They are the skeleton of your system.

Non-Functional Requirements

These describe the quality attributes — how the system behaves under real-world conditions.

Category	Question It Answers	Example
Availability	How much downtime is acceptable?	99.99% uptime (~52 min/year downtime)
Latency	How fast must responses be?	p99 under 200ms for feed loads
Scalability	How much growth must it handle?	500M daily active users
Durability	Can we afford to lose data?	Zero data loss for messages
Consistency	Must reads reflect the latest write?	Eventual consistency OK for likes
Security	What protection is needed?	End-to-end encryption for DMs

Non-functional requirements are what actually drive architecture decisions. They determine whether you need caching, replication, sharding, CDNs, or multi-region deployment.

Why the Distinction Matters

Consider this: if your functional requirement is "users can post messages" and your non-functional requirement is "support 10 QPS," a single PostgreSQL instance behind a web server handles it fine. Change the non-functional requirement to "support 100,000 QPS," and now you need load balancers, caching layers, database sharding, and a CDN — even though the feature hasn't changed at all.

2D minimalistic diagram showing the same feature (post a message) branching into two paths: low-scale path with single server and database, high-scale path with load balancer, cache, sharded database, and CDN

Common Mistakes

Jumping to architecture before gathering requirements — drawing boxes in the first minute instead of spending 5–8 minutes understanding the problem
Treating non-functional requirements as afterthoughts — availability, latency, and scale are architectural drivers, not nice-to-haves
Being vague — "the system should be fast" is not a requirement; "p99 latency under 200ms for timeline loads" is

Seeing It in Action

Scenario: You're asked to design a URL shortener.

Step 1 — Functional Requirements:

User can submit a long URL and receive a short URL
User (or anyone) can visit the short URL and get redirected to the original
User can optionally set a custom short alias
User can view click analytics for their links

Step 2 — Non-Functional Requirements:

Read-heavy: Read-to-write ratio is ~100:1 (most traffic is redirects, not creation)
Low latency: Redirects must happen in < 50ms (any delay and users notice)
High availability: 99.99% uptime — a broken shortener breaks every link using it
Scale: 100M new URLs/month, 10B redirects/month
Durability: Once a short link is created, it must work forever (or until explicitly deleted)

Notice how the non-functional requirements immediately tell you: you need heavy caching (read-heavy), you probably don't need strong consistency (a few seconds of delay for a new link to propagate is fine), and you need a database that handles high read throughput.

Interview Questions

Q: You're designing a messaging app. What functional and non-functional requirements would you gather first? Hint: Functional: send/receive messages, group chats, media sharing, read receipts. Non-functional: message delivery latency (< 500ms), durability (zero message loss), availability (99.99%), end-to-end encryption, scale (concurrent users).
Q: How do non-functional requirements influence your choice of database? Hint: High consistency needs → SQL/ACID (e.g., payments). High write throughput → wide-column store (e.g., Cassandra). Low latency reads → in-memory cache (e.g., Redis). The feature doesn't change — the quality attributes do.
Q: A system has 99.9% availability as a requirement. What does that actually mean in terms of downtime, and how does it change your architecture compared to 99.99%? Hint: 99.9% ≈ 8.7 hours/year downtime; 99.99% ≈ 52 minutes/year. The jump from 3 to 4 nines typically requires multi-AZ deployment, automated failover, and redundancy at every layer — roughly an order of magnitude more effort.
Q: What's the risk of not stating non-functional requirements explicitly in a system design interview? Hint: Without them, you can't justify any architecture decision. You might over-engineer (build for 1M QPS when 1K suffices) or under-engineer (single server for a global-scale product). The interviewer wants to see you drive the conversation by asking about scale, latency, and consistency.
Q: Can the same system have different consistency requirements for different features? Give an example. Hint: Yes — this is common. An e-commerce platform might use strong consistency for inventory/payment (you can't sell what you don't have) but eventual consistency for product reviews and recommendations (a few seconds of delay is invisible to users).

References

System Design Interview – An Insider's Guide by Alex Xu — Chapter 1: Scale from Zero to Millions of Users
Designing Data-Intensive Applications by Martin Kleppmann — Chapter 1: Reliable, Scalable, and Maintainable Applications
Google SRE Book — Service Level Objectives — how Google thinks about non-functional requirements

Dive Deeper

Non-Functional Requirements in Software Architecture — arc42's structured approach to quality requirements
Software Architecture in Practice by Bass, Clements & Kazman — the definitive treatment of quality attributes and architectural tactics
Martin Fowler — Is High Quality Software Worth the Cost? — why non-functional requirements pay for themselves