Scoping the Problem

In a system design interview, "requirements" splits into two different kinds of statement, and mixing them up is the single most common way candidates lose time in the first five minutes. A functional requirement names an action the system performs — a user posts a photo, a service redirects a short link, a rider requests a car. A non-functional requirement names how well the system has to perform that action — how many requests per second, how long a response may take, how available the service must stay, whether a lost write is acceptable. Interviewers are not grading whether you remember a diagram; they are grading whether you can turn a vague prompt into a short list of both kinds of statement before you draw a single box.

Take "design a URL shortener," a prompt most candidates have heard before. The functional list is short: accept a long URL and return a short code, redirect a short code to its long URL, and — often — let a user choose a custom alias or set an expiry. Everything else is a question, not an assumption: does a link need to work forever, or can it expire? Does the same long URL always produce the same short code, or is a fresh code fine? Each answer changes the design. The non-functional list is where the interview is actually won: redirects will vastly outnumber creations, so read latency matters far more than write latency; a redirect that takes half a second feels broken, while a create call that takes half a second does not.

A non-functional requirement only does its job once it names a number. Site reliability engineering gives this a vocabulary worth borrowing: a service level indicator (SLI) is the metric you actually measure — redirect latency, error rate, availability — and a service level objective (SLO) is the target value you set for it, such as "p99 redirect latency under 200 ms" or "99.9% of redirects succeed." A service level agreement (SLA) is what happens if you miss it — a refund, a penalty, a support escalation. "The system should be fast" is not a requirement; "p99 latency under 200 ms measured at the load balancer" is. Availability targets are usually written as a run of nines — 99.9%, 99.99% — because each extra nine is an order of magnitude harder to hold, not because the digits themselves are special.