Requirements First: The Constraints Nobody Asks About

Why this matters

The ambiguity in a design problem is not laziness on the part of whoever set it; it is the problem. Design a chat app is not a specification, and the gap between it and a specification is where all the judgement lives. Two builders given that sentence will produce completely different systems, and both can be right, because one assumed 50 people in a company and the other assumed 500 million people worldwide. Requirements are how you make your assumptions visible so that the rest of the conversation is about the design rather than about a misunderstanding. The part almost everyone skips is the third category: not what the system does, and not how fast, but the constraints that come from outside engineering entirely — where the data is legally allowed to live, how long you must keep it, what you are allowed to spend, and how many people will be on call for it. Those constraints routinely eliminate the architecture people spend twenty minutes drawing, and finding that out at minute forty is expensive.

Demo

Take a deliberately vague brief — design a ride-hailing app — and turn it into something designable in under five minutes. Three moves, in order.

Move one: cut the feature list to three. A ride-hailing product has fifty features. Pick the three that generate the interesting load: request a ride, match a driver, track the ride live. Say out loud that pricing, ratings, payments and support are out of scope for this conversation. You have just deleted 90 percent of the problem and made the remainder honest.

Move two: attach numbers and targets to those three. Not availability is important — 99.9 percent, which is 43 minutes of downtime a month, and say whether that is acceptable for matching versus for tracking. They are usually different, and noticing that they are different is worth more than the number itself.

Move three: ask the four constraint questions nobody asks. Where must the data live? How long must you keep it, and what must you be able to delete? What is the budget, in headcount-equivalents? How many people operate this? On a ride-hailing app in India, the residency answer alone can force a single-region design and delete the entire multi-region discussion before it starts.

One trap worth naming: consistency is not a single dial. Read-your-writes (a rider who just requested a ride must see it) is cheap and local. Global linearizability (no two riders can ever be matched to the same driver) is expensive and specific. If you write strong consistency in a requirements block without saying which of those you mean, you have written nothing.

Try it yourself

1. Take the block below and change residency from India-only to anywhere. Write down every design decision that becomes available again — you should find at least three, and one of them changes the database.
2. Change matching availability from 99.9 to 99.99 and compute the new monthly error budget in minutes (it drops from about 43 to about 4). Then name the single component that most likely blows that budget by itself.
3. Split consistency into the two cases shown and find a third one in the same product where the answer is different again. Write the one sentence that justifies each choice.
4. Pick a product you use and write its retention and deletion lines from the outside — what it must keep for tax or law, and what it must be able to erase. Then find the public privacy policy and check how close you were.
5. Rewrite the whole block for a system with 50 users instead of 5 million, changing nothing else. Note which lines are unchanged: those are requirements, and the ones that moved were scale assumptions wearing a requirements label.

References

• Google SRE Workbook — Implementing SLOs
• Designing Data-Intensive Applications (Kleppmann)
• GDPR Art. 44 — transfers of personal data
• AWS Builders Library — Reliability and constant work