Constraints, Assumptions, and Risks

The most elegant architecture of your career will not be the one you draw on a whiteboard; it will be the one that survives contact with the budget line, the hiring market, and the release calendar. Every real design is boxed in by forces that have nothing to do with technology, and an architect who does not inventory them will spend a quarter designing something the organization cannot build.

Constraints include budget, team skills, deadlines, and mandated technologies — plus the regulatory and contractual ones nobody mentions until legal joins the review. The inventory exercise takes an afternoon and produces the frame every later decision is checked against:

Two classifications matter more than the list itself: hard versus soft, and stated versus discovered. A hard constraint is physically or legally fixed (PII residency, a signed vendor contract). A soft constraint is organizational habit — 'we always deploy on Tuesdays' — which you must respect in the plan but should explicitly re-examine, because half the wasted effort in migrations comes from treating preferences as laws. Discovered constraints are the dangerous ones: the architect who learns in week six that the payments team cannot change its schema until after the acquisition closes has already designed around a falsehood. This is why the first interview question in any new design is not 'what do you want?' but 'what is already decided that I cannot touch?', asked separately to engineering, product, legal, and finance — they each know a different quarter of the constraints.

Record the inventory where it will be read. A constraints section at the top of the design doc, one line each, with an owner who can confirm it is still true:

## Constraints (confirmed 2026-03-04)
- [hard/legal]  Customer PII resides in eu-west-1 only. Owner: legal
- [hard/budget] Cloud spend cap $40k/mo; autoscale ceiling 60 nodes. Owner: finops
- [hard/mandated] PostgreSQL/RDS, Kafka/MSK per corp standard. Owner: platform
- [soft/skills] No new languages this year. Owner: eng-managers
- [soft/deadline] Checkout revamp targets Black Friday freeze 15 Nov.

The owner and date are what make the list alive: constraints expire, and an architecture silently built on expired ones is how teams discover in month four that the 'mandated' database standard was relaxed for new workloads. When a constraint turns out to be softer than advertised, that discovery belongs in the next design review, alongside how the design changes if it disappears. Which leads to the companion discipline: everything the design assumes but cannot yet verify — the subject of the next section — and the formal companion, Trade-off Analysis, where constraints meet the options they eliminate.

Every design contains claims about the world that nobody has verified: traffic will grow 30% year over year, the new vendor's SDK will be GA by June, the platform team will finish the shared auth service before the checkout rewrite ships, customers will tolerate a 2-second export. Recording assumptions makes them reviewable when new information arrives later — and an assumption written down is a scheduled conversation, while an assumption left in someone's head is a surprise waiting for the worst possible month.

The discipline has three moving parts: make each assumption falsifiable, assign a validation method, and give it an expiry.

Note the pattern: each row names a number or a written commitment, a way to check it without waiting for the failure, and a date at which the design must be revisited if the world has not confirmed it. Vague assumptions fail the first test — 'users will tolerate slow exports' cannot be checked, only believed; 'p95 export < 5 s accepted by 80% of pilot users' can.

Where a cheap check exists, run it instead of writing the row. The 2-hour spike that proves the vendor SDK's batch API actually batches (the docs say it does) converts an assumption into a fact for less cost than one week of engineering risk. This is the same spike habit you use for credibility in The Role of the Architect; here it is aimed at the design's load-bearing claims.

A worked example of what assumption decay looks like when skipped: the 2022-ish inventory platform at a mid-size retailer assumed 'one warehouse' because the business had one warehouse. The design put global item IDs on a single-writer sequence — perfectly correct, cheap, simple. Eighteen months later a second warehouse opened in another region, and the single-writer assumption became a throughput ceiling and a cross-region consistency problem in the same quarter. Nothing about the code was buggy. The design was correct for the world it assumed, and nobody owned re-checking the assumption as the world changed. The fix was not genius; it was a register row with a review cadence that would have caught the expansion in the planning stage, when the ID scheme was still cheap to change.

Two practical rules for running the log: keep it under a dozen active entries (a register with 40 assumptions is a graveyard nobody reads), and review the top entries in the same monthly forum that reviews incidents — the audience with the information to notice when reality moves. An assumption quietly invalidated is the highest-quality risk you can catch, because at that moment the mitigation is still a decision rather than a rescue.

Risk registers die in the same way every time: someone produces a spreadsheet with forty rows, every row scored 'high', no owner is named, and the document is never opened again. The mechanism that keeps a register alive is boring and specific: rank design threats by likelihood and impact so mitigations get funded, assign each one an owner and a trigger, and review the short list on a fixed cadence.

Score each risk on two axes, 1–5 each, and multiply for position:

Three things separate a register that works from a spreadsheet: the score is a conversation (two people who assess 'likelihood 3' differently are surfacing different information, and the argument is the point), the mitigation names a funded activity with a date ('shadow-write benchmark, sprint 9' — not 'we will monitor it'), and each row states what happens if the risk lands anyway (the contingency), because accepting residual risk knowingly is part of the job.

Mitigations come in four flavors, and picking the right one is half the interview question 'how do you handle risk?':

• Avoid — change the design so the risk cannot occur: drop the third-party payment provider whose outages caused last quarter's incidents, at the cost of two quarters of build.
• Mitigate — reduce likelihood or impact: shadow writes before cutover cut the migration risk's impact from 5 to 3.
• Transfer — buy the risk: contractually, or with an SLA-backed vendor whose credits partially cover the loss.
• Accept — consciously retain low-score risks and revisit when the design changes. Acceptance is a decision, not a default; write the sentence 'we accept up to 4 hours of data loss for event logs' where the next reviewer will see it.

Before the register is finalized, run a pre-mortem: assume it is six months from now and the project failed spectacularly; write the story of why. Pre-mortems work because they license pessimism — in normal planning, saying 'this will fail because the auth dependency will slip' sounds like disloyalty, while in a pre-mortem it is the assignment. Extract each story into a register row with a score, and the register now contains the risks the team actually fears rather than the generic ones everyone already knew.

Review discipline: the full register is read at design milestones; the top five are reviewed monthly with their owners; any risk whose score changes by 6+ points gets an immediate look. With the forces mapped and the risks ranked, you are ready to weigh options against each other under real costs — Trade-off Analysis is where that happens.