Why requirements come first
"Design a link shortener" leaves almost everything open. Can users pick their own short codes? Do links expire? Does anyone need click statistics? Are we serving a hundred people or a hundred million? Each answer changes the design.
Requirements turn the vague prompt into a short list you can design against. They come in two kinds:
- Functional requirements say what the system does: the features, written as things a user can do.
- Non-functional requirements say how well it does them: how fast, how available, how consistent, how much data, at what cost.
Functional requirements
Write them as short "users can…" sentences, then pick the few that matter most. In an interview, three is plenty: the rest go on an out of scope list so everyone agrees not to design them.
For Snip:
| Users can… | Priority |
|---|---|
| Create a short link from a long URL | Core |
| Be redirected to the long URL when they open a short link | Core |
| See how many times each of their links was opened | Core |
Choose a custom short code (snip.link/launch) | Nice to have |
| Set an expiry date on a link | Out of scope |
| Edit where a link points after creating it | Out of scope |
Notice that "out of scope" isn't "never". It's "not in this design". Saying so out loud stops you designing features nobody asked for.
Non-functional requirements
These are where most of the design comes from, and they're only useful when they're specific. "Fast" isn't a requirement; "a redirect takes under 50 ms at the server for 99% of requests" is. Here are the usual ones:
| Quality | Question to ask | Snip's answer |
|---|---|---|
| Scale | How many users, requests and records? | 10 million new links a month; about 100 redirects per link created. |
| Latency | How fast must each request be? | Redirects under 50 ms at the server for 99% of requests. Creating a link can be slower. |
| Availability | How much downtime is acceptable? | Redirects should almost never fail: a broken short link is a broken link on someone else's site. |
| Consistency | Must every reader see the latest write at once? | A new link must work the moment it's created. Click counts can lag by a minute. |
| Durability | Can we ever lose data? | Never lose a link once we've handed out its short code. |
Two things to notice. First, the numbers lead straight to design decisions: 100 reads for every write means Snip is read-heavy, so you'll design the redirect path first and hardest. Second, different features get different answers. Redirects need to be fast and always up; the stats page can be slower and a little out of date. That difference lets you build them differently.
Which of these is a non-functional requirement?
Questions worth asking
When the prompt is vague, these questions cover most of what you need. You won't ask all of them every time; pick the ones whose answers would change your design.
- Users: Who uses it? Roughly how many each day? Any very large users?
- Reads and writes: What's the ratio? Which operation is most frequent?
- Data: How big is each record? How long do we keep it? Does it ever change?
- Latency: Which requests are user-facing and need to be fast?
- Consistency: If one user writes, how soon must others see it?
- Availability: What happens to users if this is down for a minute? For an hour?
- Geography: Are users in one region or worldwide?
If the interviewer says "you decide", make a reasonable assumption, say it out loud, and write it down. That's a good answer, not a dodge.
Write the requirements for a Pastebin: users paste text and get a link anyone can open to read it. Write the functional requirements, an out-of-scope list, and at least three non-functional requirements with numbers.
Recap
Interview questions
What's the difference between functional and non-functional requirements? Give an example of each for a URL shortener.