Non-Functional Requirements in a System Design Interview

Most system design interviews are not scored on how many boxes you draw. They are scored on whether the boxes you draw have a reason to exist. The reason almost always comes from non-functional requirements: latency, availability, scalability, consistency, durability, cost. Handling non-functional requirements in a system design interview well means naming these qualities early, converting them into rough numbers, and ranking them. Candidates who do that tend to look calm and deliberate. Candidates who skip straight to services and databases tend to look like they are guessing, because they are.

This article gives you a repeatable way to surface non-functional requirements in the first five minutes, turn vague adjectives into targets you can defend, and narrate the trade-offs interviewers are listening for. It is about the skill of reasoning out loud, not about memorising a script. If you want the broader practice habits behind it, see our blog.

What Non-Functional Requirements Actually Mean in a System Design Interview

Functional requirements describe what the system does. Non-functional requirements describe how well it must do it.

• Functional: users can post a message.
• Non-functional: the post appears for followers within two seconds.
• Functional: visitors can open a short link.
• Non-functional: the redirect responds in under about 100 milliseconds at p99.

The qualities that come up most often are latency, availability, scalability, consistency, durability, cost, security, and maintainability. None of them are features. All of them shape which features you build and how.

Interviewers care because non-functional requirements are where design decisions actually get made. Choosing a cache, a queue, a replication strategy or an ID scheme only makes sense relative to a target. If you have not stated the target, your choices are arbitrary, and every follow-up question feels like an ambush.

There is a second reason. Prompts usually state these qualities vaguely, if at all. "Design a chat app" does not tell you the delivery latency target or how much ordering matters. Part of the job is making them concrete yourself, then saying so out loud.

Why Candidates Skip NFRs and What It Costs Them

The most common pattern is jumping straight to drawing services and databases. It feels productive. Boxes appear on the whiteboard, arrows connect them, and the candidate starts explaining a load balancer.

The first cost is that the design has no defensible reason for its choices. When the interviewer asks "why a queue here?", the honest answer is "because queues are common in chat systems", which is not a reason, it is a memory.

The second cost is that you cannot prioritise. If you never decided what matters most, you try to satisfy every quality at once: strong consistency and low latency and cheap storage and global scale. The result is a design that is good at nothing, and an interviewer who can tell you have not chosen anything.

A useful reframe: non-functional requirements are not extra credit you add at the end. They are the spine of the interview. Everything else hangs off them.

A Five-Minute Framework for Surfacing NFRs Early

This is the sequence to run before you draw anything complicated. It takes about five minutes and it changes the rest of the interview.

Step one: restate the functional core

One sentence. "So the core is: users create short links, and visitors get redirected to the original URL." This agrees the scope and gives you something to hang requirements on.

Step two: ask two or three clarifying questions that map to NFRs

Good questions are not generic. They target a quality:

• "Roughly what scale are we designing for, reads per second and writes per second?"
• "Is this read-heavy or write-heavy?"
• "How much staleness is acceptable on the read path?"

Notice these are not "tell me more about the requirements". They are specific enough that the interviewer can answer quickly, and their answers change your design.

Step three: write four to six NFRs with rough numbers

Not adjectives. Numbers, even approximate ones. "Redirect p99 under about 100 ms. Reads vastly outnumber writes. Link mappings must not be lost. Storage cost per link should be low."

Step four: rank them and name your first sacrifice

Say which one you would relax first if forced. "If we had to trade something, I would let cache entries go slightly stale before I would compromise durability of the mapping." This single sentence signals that you understand design is choice under constraint.

Step five: revisit at the end

Before you finish, look back at the list. Does the design still honour the ranking? If your final architecture quietly sacrificed the thing you said mattered most, say so, or fix it.

Turning Vague Qualities into Numbers You Can Defend

The skill here is translation. Each quality has a concrete conversational form.

Latency

Distinguish p50 from p99. The median request is not the one users complain about. The tail is what makes a page feel slow, so for user-facing paths, quote the tail and say why it matters.

Availability

Translate "highly available" into a rough downtime budget, and note that each additional nine is expensive. Saying "each extra nine costs real money and complexity" shows you understand the economics, not just the vocabulary.

Scalability

Express growth in reads per second, writes per second, and storage per year. "A lot of users" is not a requirement. A read rate in the thousands per second, with writes a small fraction of that, is the kind of concrete shape you want.

Consistency

Describe what a user would actually notice. Under eventual consistency, a follower might see a new post a few seconds late. That is usually fine for a feed and usually not fine for a bank balance. Say which one you are dealing with.

Durability

Separate the disposable from the precious. Losing a cache entry is an inconvenience. Losing a payment record is a different category of failure. Different data deserves different guarantees.

Cost

Cost is a non-functional requirement too. Over-provisioning is a real design failure, not a safe default. If your answer is "replicate everything everywhere", you have bought resilience with money and complexity you may not need.

The Core Trade-Offs Interviewers Expect You to Name

You do not need to recite all of these. You need to name the two or three that your prompt actually forces.

Latency versus consistency

Strong consistency usually requires coordination, and coordination costs time. If every read must see the latest write, reads get slower and more fragile, and that cost shows up on the user-facing path.

Availability versus consistency

When a partition splits the system, you generally choose between refusing some requests and serving possibly stale data. Explain it plainly: "If the network splits, I would rather keep serving slightly stale reads than reject traffic, because for this product a stale read is harmless."

Throughput versus latency

Batching improves throughput but adds delay to individual requests. That is a good fit for analytics pipelines and a poor fit for a chat message, where the user is waiting on each one.

Simplicity versus flexibility

A general solution is harder to operate than a narrow one. Building for every future use case is a way to ship nothing, and the operational cost lands on the team that has to run it.

Cost versus resilience

Redundancy buys uptime and consumes budget. The right amount depends on what an outage costs.

For each one, use the same sentence pattern: "Given X, I would choose Y, and I would accept Z as the cost." Example: "Given that a stale feed is harmless, I would choose eventual consistency, and I would accept that some users see posts a few seconds late."

Worked Example: NFRs for a URL Shortener

Functional core: create a short link and redirect visitors to the original URL.

NFRs to state:

• Redirect latency under about 100 milliseconds at p99.
• Read-heavy traffic, far more redirects than creations.
• Very high availability on the redirect path, so it keeps serving even when other parts of the system are degraded.
• Durability of the link mapping, once created it must not vanish.
• Low storage cost per link.

Design consequences follow directly. Cache aggressively on the read path, because reads dominate and latency is tight. Keep the write path simpler, because it is rare and can afford a little more work. Choose an ID scheme that avoids coordination, since coordinating every link creation buys you nothing here.

The trade-off to narrate: accepting slightly stale cache entries in exchange for fast redirects. Close by restating which NFR you would relax first if the interviewer tightened the constraints, for example relaxing the latency target before relaxing durability.

Worked Example: NFRs for a Chat or Feed System

Functional core: users send messages and see them in near real time.

NFRs to state:

• Message delivery latency, tight enough to feel live.
• Ordering per conversation.
• Durability of sent messages.
• Availability during traffic spikes.
• Reasonable storage growth over time.

Design consequences differ from the shortener. Persistent connections suit delivery. Ordering is scoped per conversation rather than globally, which is cheaper and sufficient. Messages are stored durably before acknowledgement, because a message the user believes was sent should not disappear.

The trade-off to narrate: global ordering would be simpler to reason about but far more expensive to guarantee, so scope ordering to the conversation. Notice how a different NFR list produces a different design from the same framework. That is the point. It is not a template you paste onto every prompt.

How to Talk About NFRs Without Sounding Rehearsed

A few habits keep this natural.

• Use plain language first, then the term. Describe the behaviour, then name the concept. "If the network splits, I would keep serving reads that might be a few seconds old. That is an availability-over-consistency choice."
• Say your assumptions out loud and invite correction. "I am assuming reads outnumber writes by a lot. Does that match your intent?" This turns the interview into a collaboration rather than a test.
• When you do not know a number, give a defensible order of magnitude and label it as an estimate. "I would guess a few thousand reads per second. That is an estimate."
• Avoid listing every quality you have memorised. Pick the ones that matter for this prompt and let the others go.
• Practise explaining the same trade-off in thirty seconds and in two minutes, because interviewers interrupt at different points.

Practising NFR Reasoning Before the Interview

This is a trainable skill, and it improves faster with deliberate repetition than with more reading.

• Pick five familiar systems and write four NFRs for each with rough numbers, then rank them and name your first sacrifice.
• Record yourself answering one prompt and check whether you stated NFRs before drawing components. Most people do not, the first time.
• Review the recording for filler phrases that hide uncertainty, and replace them with explicit assumptions.
• Rehearse the trade-off sentence pattern until it feels like your own speech, not a formula.
• Keep a short personal list of trade-offs you can explain confidently, and be honest about the ones you cannot yet.

If you are working through related fundamentals, our article on Python interview questions: concepts and trade-offs uses the same reasoning style, and our support page explains how to get help when a practice session is not going the way you want. For what counts as fair practice, see our authorized use policy.

The takeaway: before you draw a single box, say what the system must optimise for, put rough numbers on it, rank the list, and name what you would give up first. Everything you design afterwards becomes easier to justify, and the interview starts to feel like a conversation about engineering rather than a memory test.

Frequently asked questions

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

Functional requirements describe what the system does, such as letting users create a short link. Non-functional requirements describe how well it must do it, such as redirect latency under about 100 milliseconds at p99, or durability of the link mapping. Functional requirements define scope; non-functional requirements define the constraints that make your design choices defensible.

How many non-functional requirements should I mention before starting the design?

Four to six is usually enough. Fewer than that and you have not given yourself enough constraints to reason with. More than that and you will spend the interview listing qualities instead of designing. Pick the ones that genuinely change your architecture for this prompt, and let the rest go.

What if the interviewer never asks about non-functional requirements?

Raise them yourself. The prompt is usually vague about latency, scale and consistency, so making them concrete is part of the job. State a few assumptions with rough numbers and invite the interviewer to correct you. That turns an unasked question into a collaboration rather than a gap in your answer.

Do I need exact numbers for latency and availability targets?

No. Defensible orders of magnitude are enough. Say that you are estimating, give a rough figure, and explain what would change if the real number were an order of magnitude higher or lower. Interviewers are listening for whether you reason with numbers, not whether you memorised them.

Which trade-off should I prioritise if the interviewer pushes back on my choice?

Return to your ranked list and say which requirement you would relax first. For example, if durability matters more than latency for the data in question, hold durability and let the latency target slip. Naming the sacrifice explicitly is usually a stronger answer than defending the original choice.

Can I bring a written NFR checklist into a real interview?

Check the instructions you were given and follow them, because expectations differ between interviews and employers. The safer preparation is to internalise the framework through practice so you can run it from memory without relying on notes.

Rehearse the five-minute framework on a prompt you know well.