A team must ship a compliance-driven reporting system by a fixed statutory date nine months away. There are three engineers, no operations staff, an existing Postgres database, and no budget for new licences. Which constraint should drive the architecture?
Show the full answer Hide the answer
The deciding property
Every item on that list is a real constraint. The question is which one removes options from the design rather than merely applying pressure to it.
The lack of operations staff is the binding one, because it disqualifies whole architectures. Three engineers who also carry the pager cannot run a Kafka cluster, a Spark deployment, a self-hosted search index and a service mesh, whatever the date says. Every component chosen is a component someone must upgrade, patch, back up, and be woken up for, forever — and the people who will do that are the same three people writing the features.
That single fact settles most of the design: managed services or nothing, the fewest moving parts that satisfy the requirement, the boring database you already operate, and scheduled batch processing instead of a streaming topology.
The arithmetic is worth doing out loud, because it is what makes the constraint concrete rather than a feeling. A sustainable 24-hour rota needs 5 or 6 people; with 3 you have a rota that fails on the first holiday. Each self-hosted component adds a major upgrade every 6 to 12 months, and every hour spent on that is an hour not spent on a statutory deadline. The cost is paid after go-live, in the year when nothing new ships because three people are keeping in production what four components demand. Google's SRE book named this class of work toil in 2016, and the number it recommends capping is the share of time it consumes, which is exactly the number a three-person team has none of.
Why not the others
- The statutory date. It is fixed and it is a scope constraint, not a structural one. It tells you how much you can build, and it does not tell you what to build; teams routinely meet dates with architectures they cannot operate, and the bill arrives the month after go-live.
- The existing Postgres. A strong default and an argument, not a constraint — you could add something else. Notice it usually agrees with the answer, which is why it feels compelling.
- The licence budget. It removes some products from a list. Open-source alternatives exist for everything here, and choosing them makes the operability problem worse, because free software is free to acquire and not free to run.
What would flip the decision
| If this changes | The binding constraint becomes | Because |
|---|---|---|
| A platform team will operate what you build | The statutory date | Operability is somebody's job, so scope is the limit |
| The date moves out by two years | Data volume and query patterns | With time, the design can be built for what it must eventually do |
| A regulator mandates on-premise deployment | The deployment target | Managed services stop being available and the operability problem returns |
| Headcount doubles to six with an on-call rota | The date again | Capacity to operate rises; capacity to deliver is now the limit |
The general rule
Rank constraints by how many designs they eliminate, and design against the top one. A constraint that eliminates nothing is a preference. This is also why "we need it to be fast" is not a constraint until it is a number attached to a request path, and why the most valuable early question is usually about the team rather than the workload.
When this is the wrong answer
If the system must run where you cannot buy managed services — an air-gapped environment, a regulated on-premise estate, a country with no local cloud region — then the deployment target outranks everything, including your headcount, because it decides what exists to choose from. And on a genuinely short deadline with a trivial workload, the honest answer is that no constraint is binding: build the simplest thing in the database you have and stop analysing.