Requirements to Constraints

A requirement is what somebody asked for. A constraint is what that request forbids you from building. Architecture happens in the translation between the two, and most weak architectures skip it.

The translation

"The meeting must start instantly" is not designable. Push on it and you get: median join time under 2 seconds, p99 under 5 seconds, from any continent, on a 3G connection, for a meeting of up to 1,000 participants. Now it is a constraint. It rules out a design that authenticates against a single home-region identity service, because the round trip alone eats the budget.

The useful questions are mechanical:

• How much, how often, how fast? Volume, rate, latency percentile.
• What happens if it fails? Money, safety, reputation, regulatory exposure.
• Who says so, and can they change their mind? A constraint from a regulator is different in kind from one from a product manager.
• When does it bite? Peak, not average. Average load never designed anything.

Industry example

Zoom's early-2020 growth from roughly 10 million to 300 million daily meeting participants did not change any functional requirement. Nobody asked for a new button. What changed was one constraint — concurrent capacity — and it invalidated assumptions about data-centre pre-provisioning, media routing and vendor concentration that had been perfectly reasonable at the previous scale. The functional spec was stable throughout; the architecture was not.

Failure mode

The classic failure is accepting an adjective. "Highly available", "real time", "secure", "scalable". Every one of those passes review and none of them can be tested, so they are settled later by whoever is loudest during the incident.

The second failure is deriving constraints from today's traffic and never revisiting them. A constraint has a shelf life; write down the volume assumption next to it so it is obvious when it expires.

Trade-off

Tightening a constraint always costs something. A p99 of 100 ms instead of 300 ms may triple the infrastructure bill and force a cache layer that introduces staleness. The architect's job is to make that price visible to the person asking, before the design is committed rather than after.

Interview question

"A stakeholder says the system must be 'always available'. Walk me through how you turn that into something you can design and test against."