Functional vs Non-Functional Requirements

Table of Contents +

You sit down in a system design interview and the interviewer says, “Design Instagram.” The worst thing you can do is start drawing servers right away. The best thing you can do is slow down and ask: what should this system actually do, and how well should it do it? Those two questions are functional and non-functional requirements, and listing them first is what separates a strong candidate from a nervous one. Let’s learn both.

🎯 The Two Kinds of Requirements

Every system has two kinds of requirements, and they answer two different questions:

Functional requirements answer: what does the system do? These are the features. The actions a user can take.
Non-functional requirements answer: how well does it do those things? These are the qualities. Speed, scale, reliability.

Here’s the simplest way to hold it in your head: functional is the what, non-functional is the how well. A system can have all the right features (functional) but still fail if it’s slow or keeps crashing (non-functional).

⚙️ Functional Requirements

Functional requirements are the features, the things a user can actually do with the system. For “design Instagram,” they might be:

A user can upload a photo.
A user can follow other users.
A user can see a feed of photos from people they follow.
A user can like and comment on photos.

Notice these are all concrete actions. You can picture a user doing each one. That’s the test of a functional requirement: it’s something the system does.

Keep functional requirements focused

In an interview you can’t build everything, so list the core features and confirm with the interviewer which ones to focus on. Saying “I’ll focus on upload and feed, and set aside messaging for now” shows good judgment.

📊 Non-Functional Requirements

Non-functional requirements are the qualities, how well the system must do its job. These don’t add features; they shape how you build them. The common ones:

Scalability: can it handle millions of users? (See scalability.)
Availability: is it up and working when people need it?
Performance: is it fast? Do photos load quickly?
Reliability: does it avoid losing data or showing wrong results?
Consistency: does everyone see the same data?

These are the qualities that decide your actual design choices. “Must handle millions of users” pushes you toward load balancers and caching. “Must never lose a photo” pushes you toward replication.

🔗 Why Non-Functional Drives the Design

Here’s the insight that makes this lesson click. The functional requirements tell you what to build, but the non-functional requirements tell you how to build it.

Think about it:

“Show a user’s feed” is the feature (functional).
“The feed must load in under a second for 100 million users” is the quality (non-functional), and that is what forces you to add caching, spread data across servers, and so on.

So two systems with the exact same features can look totally different inside, all because their non-functional requirements differ. A note-taking app for 100 users and one for 100 million users do the “same thing,” but they’re built completely differently.

Get rough numbers early

Non-functional requirements are much more useful with numbers. “How many users? How many photos per day?” Those figures drive your capacity estimation and your design. Always ask for them.

📋 A Side-by-Side Example

Here’s “design Instagram” split into both kinds, so the difference is concrete.

Functional (what)	Non-functional (how well)
Upload a photo	Handle 100 million users
Follow other users	Feed loads in under 1 second
See a feed	Never lose an uploaded photo
Like and comment	Stay up 99.9% of the time

🧭 How to Use This in an Interview

The first few minutes of a design interview should go like this:

Ask clarifying questions, then state the functional requirements (the core features).
State the non-functional requirements (scale, speed, reliability), and ask for rough numbers.
Confirm with the interviewer before you start designing.

This shows you think before you build, and it gives you a checklist to design against. Every choice you make later, you can tie back to a requirement. That’s exactly the structured thinking interviewers are grading.

⚠️ Common Mistakes and Misconceptions

A few things to keep straight:

“Jump straight into drawing boxes.” This is the classic mistake. Without requirements, you’re designing blind. List them first, always.
“Non-functional requirements are optional extras.” No, they drive the whole design. Scale and reliability decide which pieces you even need.
“List every possible feature.” You can’t build them all in an interview. Pick the core few and confirm scope with the interviewer.

🧩 What You’ve Learned

Nice work. Here’s the recap:

✅ Functional requirements are what the system does: its features and user actions.
✅ Non-functional requirements are how well it does them: scale, speed, availability, reliability, consistency.
✅ Non-functional requirements drive the design; the same features at a bigger scale need a very different system.
✅ Get rough numbers early, since they shape your estimates and choices.
✅ In an interview, list both first and confirm scope before you start designing.

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

🚀 What’s Next?

You know how to frame a problem. Let’s keep building your interview process.

Requirement Gathering goes deeper on the questions to ask up front.
Capacity Estimation turns those rough numbers into a real sense of scale.

Get these down and you’ll start every design interview on the right foot.

Previous The System Design Interview Process Next Requirement Gathering in System Design Interviews

Share & Connect

Share on LinkedIn