Functional vs. Non-functional Requirements

Functional Requirements

These are the things a user can do. The test is simple: you can answer yes or no. Either the feature exists or it does not.

For a URL shortener:

• A user can submit a long URL and get a short one back.
• Visiting a short URL redirects to the original.
• A user can optionally choose a custom alias.
• A link can be given an expiry date.

Write three to five of these and stop. The real skill here is not listing features, it is cutting them.

An interviewer who says "design Twitter" is not expecting Twitter. They are expecting you to say something like: "I'll cover posting, following, and the home timeline. I'm leaving out search, direct messages, ads and trending for now. Does that match what you want to focus on?"

That single sentence does three things. It shows you can scope work, it stops you spending forty minutes on the wrong subsystem, and it gives the interviewer a chance to redirect you. Candidates who skip it often build something impressive that was never being assessed.

Non-Functional Requirements

These describe the qualities of the system. The test is different: a good non-functional requirement has a number in it.

"The system should be fast" is not a requirement, it is a wish. "p99 read latency under 50 ms" is something you can design for and be measured against.

The ones worth asking about, roughly in the order they change your design:

Scale. How many users, and how much traffic? Daily active users, requests per second at peak, and how much data is stored per year. This drives almost everything else.

Latency. How fast, stated as a percentile. Always ask for p99 rather than an average, because averages hide the slow requests users actually notice.

Read to write ratio. A hundred reads per write points you at caches and replicas. The reverse points you at queues and write-optimised storage.

Availability. What downtime is acceptable? It is worth knowing what the numbers mean per year:

Every extra nine costs real money and real complexity. A candidate who says "99.999%" without being asked has usually not thought about the price.

Consistency. Must every reader see a write immediately, or is a short delay acceptable? This is rarely one answer for the whole system. Account balances need strong consistency; a view counter does not.

Durability. Is losing data acceptable, and if so, how much? Photos and payments are different from analytics events.

Security and privacy. Authentication, authorisation, encryption, and any regulation that applies to the data.

Cost. Rarely stated, always real. It is a good sign when a candidate mentions that a design would be expensive and offers a cheaper option.

Each Non-Functional Requirement Points at a Decision

This mapping is the reason the requirements phase matters. Every quality attribute suggests specific components and techniques:

If you gather non-functional requirements and then design as though you had not, an interviewer will notice. The requirements should visibly drive your choices, and the strongest thing you can do later in the interview is refer back to them: "I'm adding a cache here because of the hundred-to-one read ratio we agreed at the start."

How to Run This Phase in an Interview

Spend about five minutes. Long enough to get the numbers, short enough to leave time for the design. Requirements gathering that runs fifteen minutes is a common way to fail the second half of an interview.

Write them down where you and the interviewer can both see them. You will refer back to them repeatedly.

Ask for numbers, and if you do not get one, assume out loud. Interviewers often leave scale vague deliberately. "You haven't given me a number, so I'll assume 100 million daily active users and about 500,000 redirects per second at peak. Tell me if that is wrong." That is much better than either guessing silently or stalling.

Turn the numbers into something usable. A hundred million users doing five actions a day is roughly 5.8 thousand requests per second on average, and peak is several times that. Doing that conversion early gives you the figure you will need when you size the system.

Do not recite a generic list. Saying "it should be scalable, available, secure and maintainable" about every system tells the interviewer nothing. Pick the two or three that actually shape this design and put numbers on them.

💡 In the interview: open every question the same way, and keep it to five minutes. State three to five functional requirements and explicitly say what you are leaving out. Then get numbers for scale, latency and availability, assuming out loud where the interviewer does not supply them. Finish the phase with one sentence that sets up everything after it, such as: "So this is read-heavy at roughly a hundred to one, needs p99 under 50 ms globally, and can tolerate eventual consistency on the redirect. That points at heavy caching and a CDN, and it means I do not need distributed transactions." An interviewer who hears that sentence already knows that the rest of your design will be deliberate.

Key takeaway: functional requirements describe what the system does and are answered yes or no; non-functional requirements describe how well it does it and should always include a number. Functional requirements determine which components appear in your design, while non-functional requirements determine how many there are, where they are located and how they connect. That is why the same feature at two different scales produces two different systems. Spend about five minutes, scope the features down explicitly, get or assume concrete numbers, and let those numbers visibly drive the decisions you make afterwards.