Concept · Requirements & scale
Clarifying requirements
Turn a vague prompt into users, features, scale and constraints before drawing a single box.
Every design starts from a sentence like "design a photo-sharing app". Clarifying requirements turns that into a short, specific list you can design against — and, just as usefully, a list of things you are not building.
The questions worth asking
| Area | Ask | Why it matters |
|---|---|---|
| Users | Who uses it? Consumers, businesses, internal staff? How many? | Sets scale, security and latency expectations |
| Core actions | What are the three things users must be able to do? | Everything else is optional |
| Data | What's created, how big is it, how long is it kept? | Drives storage and cost |
| Reads vs writes | Which happens more, and by how much? | Decides where caching and replicas help |
| Freshness | How soon must a change be visible, and to whom? | Decides the consistency model |
| Constraints | Regions, compliance, budget, existing systems? | Rules options out early |
Cut scope on purpose
List features, then mark each in or out. "Out" isn't failure; it's a decision that buys time for the parts that matter. A pastebin without accounts, search or comments is still a pastebin, and much easier to make reliable.
Write the answers down
Turn the answers into one-line requirements: "users create pastes up to 1 MB", "links expire after a chosen period", "reads must not fail when writes do". Keep them visible while you design; each later decision should point back to one of them.
The non-functional requirements note covers how to turn "fast" and "reliable" into numbers.