Updated 26 October 2026

Functional vs non-functional requirements in system design

How to write the requirements in a system design interview: functional vs non-functional requirements with examples, how to put a number on each, typical targets for chats, feeds, payments, video and search, the clarifying questions to ask, and the mistakes that cost candidates the first five minutes.

The first five minutes of a system design interview decide what the next forty are about. Functional requirements say what the system does: the features a user or a client can use. Non-functional requirements say how well it must do them: scale, latency, availability, consistency, durability, security and cost, each with a number. The functional list fixes the scope; the non-functional numbers decide the architecture. Two candidates who design "a URL shortener" with 1,000 redirects a second and with 1 million a second are designing different systems.

Functional requirements

A functional requirement is something the system lets someone do, stated as a capability: "users can send a message to a channel", "a short link redirects to its destination", "a rider can request a trip and see the driver approach". Write them as verbs the user or a client performs, not as components ("a cache") or qualities ("fast").

• Aim for 4 to 8, then mark the core two or three. In a 45-minute round you will design the core in depth and mention the rest.
• Say what is out of scope. "Out of scope: search, file uploads, admin tools." Naming non-goals is a sign of seniority: it shows you know where the time should go.
• Agree them before moving on. One sentence is enough: "I'll focus on sending and receiving messages and history; presence and search if we have time. Does that match what you want?"

For a URL shortener the functional list might be: create a short link for a long URL (optionally with a custom alias and an expiry); redirect a short link to its destination; count clicks per link; and, out of scope, user accounts, link editing and abuse review beyond a blocklist.

Non-functional requirements

A non-functional requirement is a quality the system must have, and in an interview it is only useful with a number attached. "It should be fast" is not a requirement; "a redirect in under 50 ms at the 99th percentile, worldwide" is, and it rules out designs that cross an ocean on every request.

You will not need all of them. Pick the four to six that matter for this system, and say which one drives the hardest trade-off. In a chat system it is fan-out to large channels; in payments, exactly-once money movement; in a feed, read latency against the cost of precomputing timelines.

Typical targets by kind of system

Interviewers rarely give you numbers; you propose them and they adjust. These are reasonable starting points, from the reference designs on this site:

The clarifying questions to ask

Clarifying questions are how you turn the prompt into requirements. Ask a handful, not twenty, and propose an answer when the interviewer turns the question back to you.

Users and features

1. Who uses it, and what are the two or three things they do most?
2. Which features are in scope for this conversation, and which can we leave out?
3. Is there a mobile client, a web client, an API for other developers, or all three?

Scale

1. How many daily active users, and how many at peak?
2. What is the read-to-write ratio for the core operation?
3. How large is a typical item (a message, a video, a document), and how long do we keep it?
4. Is there a hot spot: a celebrity account, a viral item, an on-sale moment?

Quality

1. What latency does the core operation need, and is that at the median or the 99th percentile?
2. What happens if a user sees slightly stale data? Where is that unacceptable?
3. Can we ever lose an acknowledged write?
4. What availability is expected, and should it survive the loss of a whole region?

Constraints

1. Are there regulatory or privacy constraints: payments, health data, where data may live?
2. Do we build on existing infrastructure or start from nothing?

If the interviewer says "you decide", decide out loud and write it down: "I'll assume 100 million daily users and a 10 to 1 read ratio; tell me if that is off."

Writing them on the board

Keep the requirements visible for the whole interview, in a corner of the board or the top of the document, as two short lists:

Functional
- create short link (custom alias, expiry)
- redirect short -> long
- count clicks
- out of scope: accounts, editing, abuse review

Non-functional
- 100 M new links/month, 10 B redirects/month (~4 k/s avg, ~40 k/s peak)
- redirect p99 < 50 ms worldwide          <- drives the design
- 99.99 % for redirects; creation can degrade
- no lost mappings; analytics may lag minutes

Then refer back to them. When you choose a cache, point at the latency line; when you defer analytics to a stream, point at "may lag minutes". Interviewers grade whether your design follows from your requirements.

Mistakes to avoid

• Listing qualities without numbers. "Scalable, highly available, low latency" says nothing. Every system wants those; the numbers are what make yours specific.
• Too many features. Ten functional requirements means none of them gets designed properly. Pick the core and say what you are leaving out.
• Spending fifteen minutes here. Five to eight minutes for requirements, then move on. You can revisit a number when the design needs it.
• Never naming the hard part. A strong candidate says "the hard part of this problem is X" before drawing a box.
• Forgetting the requirements once the design starts. If a choice does not trace back to a requirement, the interviewer will ask why it is there.

The next step after requirements is back-of-envelope estimation: turning the scale numbers into requests per second, storage per year and the count of whatever is under pressure. The interview framework covers the rest of the hour.

Questions people ask

What is the difference between functional and non-functional requirements in system design?

Functional requirements say what the system does: the capabilities a user or client can use, such as sending a message or redirecting a short link. Non-functional requirements say how well it must do them: scale, latency, availability, consistency, durability, security and cost, each with a number. The functional list fixes the scope; the non-functional numbers decide the architecture.

What are examples of non-functional requirements?

Scale (100 million daily users, 40,000 requests a second at peak), latency (a redirect in under 50 ms at the 99th percentile), availability (99.99 %, about 53 minutes of downtime a year), consistency (reads may be up to 5 seconds stale), durability (no acknowledged write is ever lost), correctness (never sell a seat twice), security and privacy rules, and cost per user or per request.

How many requirements should I list in a system design interview?

Four to eight functional requirements, with the core two or three marked and the rest named as out of scope, and the four to six non-functional requirements that matter for this system, each with a number. Spend five to eight minutes on them, then move on; you can revisit a number when the design needs it.

What clarifying questions should I ask in a system design interview?

Ask who uses the system and what they do most, which features are in scope, how many daily users and requests there are at peak, the read-to-write ratio, how large an item is and how long it is kept, where hot spots appear, what latency the core operation needs, where stale data is unacceptable, whether an acknowledged write may ever be lost, and what availability is expected.

What does 99.99 % availability mean?

It means the system may be unavailable for at most 0.01 % of the time: about 53 minutes a year, or 4.4 minutes a month. 99.9 % allows about 8.8 hours a year and 99.999 % about 5 minutes. Each extra nine usually costs redundancy, automatic failover and often a second region, so ask which paths need it rather than applying it everywhere.