LESSON 1.2
Finding the requirements
Functional requirements say what the system does; non-functional requirements say how well. Nobody hands you either, so you learn to ask.
6 min read
A doctor tells you, "I want my patients to book appointments online." That sentence is the whole brief. Everything a real design needs is hidden behind it, and your job is to dig it out.
Requirements come in two kinds.
Functional requirements: what it does
Functional requirements are the features: the things a user can do. They are usually phrased as "users can …".
For a URL shortener:
- Users can submit a long URL and get a short one back.
- Visiting the short URL redirects to the long URL.
- Optionally: users can pick a custom alias; links can expire.
Keep the list short. Three to five core features is plenty. Every feature you add is something you have to design, store and scale. In an interview, it is completely fine, and wise, to say: "I'll focus on creating and following links; analytics and custom domains are out of scope."
Non-functional requirements: how well it does it
Non-functional requirements are the qualities the system needs. They are the ones that actually decide your architecture. Two systems with identical features can need completely different designs because of them.
The ones that come up again and again:
| Quality | The question to ask | Example answer |
|---|---|---|
| Scale | How many users, requests, how much data? | 100M new links a month, 10B redirects |
| Latency | How fast must it feel? | Redirect in under 50 ms (p99) |
| Availability | How much downtime is acceptable? | 99.99%: redirects must work even when link creation is down |
| Consistency | Can users ever see stale or conflicting data? | A new link may take a second to work everywhere |
| Durability | Can we ever lose data? | Never lose a created link |
| Read/write ratio | Is it read-heavy or write-heavy? | 100 reads for every write |
How to find them
Nobody hands you a requirements document. You find requirements by asking questions, and by reasoning about the product when nobody is there to ask.
- Who uses it, and for what? Patients booking, the doctor viewing the schedule, a receptionist rescheduling. Each role is a set of features.
- What is the core action? For booking it is "reserve a slot". Everything else supports that.
- What would be a disaster? Two patients booked into the same slot. That is a consistency requirement.
- How big does it get? One clinic, or every clinic in the country? That single answer can move you from one server to a distributed system.
- What can be slow or slightly wrong? A dashboard that is a minute out of date is usually fine. A booking confirmation is not.
Requirements drive every later decision
Watch how one requirement ripples through a design:
- "Redirects are 100x more common than creates" → optimize the read path: cache hot links.
- "Never sell a seat twice" → reservations need transactions or locks, not just eventual consistency.
- "Feeds can be a few seconds stale" → you can precompute feeds in the background.
- "Must survive a data center outage" → replicate to another region.
If you cannot point at the requirement that justifies a component, that component probably should not be in your design.
Try it
Notification Service HLD
Practice separating what the system does from how reliably and quickly it must do it.