Non-Functional Requirements Examples for System Design Interviews
Non-functional requirements say how well a system must work rather than what it does. In a system design interview, each one should come with a number. "The system must be highly available" is not a requirement an interviewer can design against. "The read path must reach 99.99 percent availability, which allows about 53 minutes of downtime a year" is. The table below lists the requirements that come up most often, the figure an interviewer expects, and a sentence you can say for each one.
Non-Functional Requirements With Numbers
| Requirement | The number to give | How to say it |
|---|---|---|
| Availability | 99.9 percent (about 8.8 hours down a year) or 99.99 percent (about 53 minutes) | "Reads target 99.99 percent; writes can accept 99.9." |
| Latency | p99 under 200 ms for a user-facing read | "p99 means 99 of every 100 requests finish faster than 200 ms." |
| Throughput | Requests per second, derived from daily active users | "10 million users at 100 reads each is about 11,600 reads per second." |
| Read/write ratio | 100 to 1 for a feed, near 1 to 1 for chat | "Reads dominate, so the design centers on caching." |
| Durability | 11 nines (99.999999999 percent) for stored objects | "Storing 10 million objects, we expect to lose one about every 10,000 years." |
| Consistency | Strong for payments, eventual for feeds | "A balance read after a write must show the write; a feed may lag a few seconds." |
| Scalability | 10x growth without a redesign | "Ten times today's load by adding machines, not by changing the design." |
| Storage growth | Bytes per record times records per day | "1 KB per post at 10 million posts a day is 10 GB a day, about 3.7 TB a year." |
| Recovery point objective (RPO) | Minutes of data that may be lost, such as 5 | "RPO is the most data we may lose after a failure, measured in time." |
| Recovery time objective (RTO) | Minutes until service returns, such as 30 | "RTO is how long the system may stay down after a failure." |
| Security | Encryption in transit and at rest; authentication on every endpoint | "TLS on every connection, encrypted disks, tokens that expire in one hour." |
| Maintainability | A change deployed with no downtime | "Rolling deploys, and a rollback in under 10 minutes." |
| Observability | Metrics, logs, and traces on every service | "Alert when p99 latency or the error rate stays above the limit for 5 minutes." |
| Cost | A budget per unit of work | "Under one cent per 1,000 requests at the expected load." |
The availability figures are worth memorizing because interviewers ask for them directly. A year has 8,760 hours, and the allowed downtime is the fraction of that year the target does not cover.
| Availability | Downtime allowed per year |
|---|---|
| 99 percent | About 87.6 hours (3.65 days) |
| 99.9 percent | About 8.8 hours |
| 99.99 percent | About 53 minutes |
| 99.999 percent | About 5.3 minutes |
Each extra nine cuts the allowed downtime by a factor of ten. Each one also adds redundancy that must be designed, paid for, and tested.
How to Derive the Numbers in Five Minutes
Start from the users, because every other number follows from them. Ask for the number of daily active users, and if the interviewer has no figure, propose one, such as 10 million. Then ask how many times a day a typical user reads and writes; for a social feed, 100 reads and 1 write is a reasonable guess.
The arithmetic then takes about a minute. One billion reads a day divided by 86,400 seconds is about 11,600 reads per second on average, and 10 million writes a day is about 116 per second. Traffic is not even across the day, so multiply by a peak factor of 2 to 3. That gives about 35,000 reads per second and about 350 writes per second at peak. If each post is about 1 KB, writes add 10 GB a day, about 3.7 TB a year, and about 18 TB over five years.
Say these figures out loud as you derive them, and write them at the top of the whiteboard. Every later choice, from the cache size to the number of database shards, is justified by one of them.
Functional vs Non-Functional Requirements
Functional requirements say what the system does. A user can post a message, follow another user, or refund a payment. Non-functional requirements say how well it does those things, and they are useful only with a number attached. The full definitions of both kinds, with more examples, are in What are functional and non-functional requirements?. In the interview, spend about two minutes on the functional list and three on the non-functional numbers, because the numbers decide the design.
Two related pages help with the borderline cases. What are the valid non-functional requirements? lists which qualities count, and Are non-functional requirements the same as technical requirements? separates them from implementation constraints.
Three Common Mistakes
Listing requirements without numbers. "Low latency" and "highly scalable" give the interviewer nothing to check the design against. Every entry gets a figure, even if the figure is a stated assumption.
Choosing 99.999 percent for everything. Five nines allows about 5.3 minutes of downtime a year, which requires redundant copies of every part, automated failover, and usually more than one region. Give that target only to the path that needs it, such as payments, and give the rest 99.9 or 99.99 percent.
Forgetting the read/write ratio. The ratio decides the design. A 100 to 1 ratio calls for caching and read replicas. A ratio near 1 to 1, as in chat or logging, calls for a fast write path, queues, and partitioning. A worked example of a reliability figure is in What is an example of a reliability non-functional requirement?.
How to Prepare
- Memorize the downtime table. 99.9 percent is about 8.8 hours a year, 99.99 percent about 53 minutes, and 99.999 percent about 5.3 minutes.
- Practice the five-minute derivation on three products. A feed, a chat application, and a ride-hailing app produce three different read/write ratios.
- Write the numbers before the diagram. In every practice session, put the figures at the top of the page first and refer to them as you design.
- Learn the full method. Grokking the System Design Interview opens every case study with this requirements step.
- Study the underlying concepts. Grokking System Design Fundamentals explains availability, consistency, and durability in depth.
GET YOUR FREE
Coding Questions Catalog
$98
$197
$72
