Decision Trigger

Architectural decisions are made once and rarely reviewed. Without a mechanism, two failure modes follow: the premature change, driven by a general sense that something could be done better, and the indefinite acceptance of a choice that stopped making sense years ago.

A decision trigger is a specific, measurable condition recorded with the decision: "we revisit when this service costs more than two fully-loaded engineers", "when write volume exceeds X", "when the corpus exceeds ten million documents", "when we have more than two thousand tenants".

Why it matters

It converts an invisible assumption into a monitored one. The assumption behind most architectural choices is a scale, a cost or a requirement that was true at the time, and nothing in the system announces when it stops being true.

It also removes the emotional content from the argument. A team proposing a change against a trigger has evidence; one proposing it without has a preference — and the trigger makes that distinction available to both sides.

Implementation patterns

• Record it in the decision record, alongside the rejected options — "the conditions that would make this wrong" is the most valuable and least written section of an ADR.
• Make the condition measurable and, where possible, monitored. A trigger nobody can evaluate is a sentiment.
• Prefer a number to a judgement. "When the team says it is painful" is not a trigger; "when the p99 exceeds our budget for two consecutive weeks" is.
• Include the direction that would justify staying, not just leaving, so a review is genuinely a review.
• Attach it to the class of decision that is expensive to reverse. Applying the discipline to every choice produces an archive nobody reads.
• Review the trigger list periodically, since some triggers become irrelevant when the business changes.

Industry example

The managed-versus-self-hosted question — for a database, a search engine, a streaming platform — is the canonical case. Platforms such as Supabase, Render and Railway exist because operating infrastructure well is expensive, and the honest position is that buying is more cheaply reversible than building: a team that bought has a working system to migrate and knows what it needs, while a team that built has an integration project, a decommissioning project and skills invested in the wrong place.

That asymmetry is why the default should be to buy with a trigger, rather than to build in anticipation.

Failure scenarios

• No trigger, so a choice is either changed on preference or never.
• A trigger expressed as a feeling, which cannot be evaluated.
• A trigger recorded and never monitored, which is the same as none.
• Triggers on every decision, producing noise that hides the ones that matter.
• A trigger fired and ignored, which is worse than none because the organisation now knows and did not act.

Trade-offs

Defining triggers requires estimating thresholds that may be wrong, and a badly chosen trigger fires too early or never. It also adds a small overhead to every significant decision.

The mitigation is that a rough trigger is far better than none — the point is to create a review, not to predict the future precisely — and a trigger that turns out to be wrong is itself information worth having when it fires.

Interview question

"You chose a managed database three years ago. Under what circumstances would you move off it, and how would you know those circumstances had arrived?"