Precondition Audit

Patterns are compressed experience: a recurring problem, a solution, and the reasoning connecting them. They are the most efficient tool in architecture, because most problems are not novel and recognising which known problem this is, is far faster than deriving a solution.

The compression discards something. A pattern's description states the problem and the solution and rarely states its preconditions — the scale, the team structure, the failure model, the cost profile and the organisational capability the solution assumes. Those preconditions are exactly what determines whether the pattern will work here.

A precondition audit makes them explicit and checks each one.

Why it matters

The most expensive errors in architecture come from patterns applied where their preconditions are absent, and they are difficult to argue against because the pattern is genuinely good and carries a respected name.

The failure is not identifiable from the outcome for a long time. A cell-based architecture adopted without the automation to operate many cells does not fail immediately; it produces an operational burden that accumulates. Event sourcing adopted in a domain where history is not the truth produces a projection that becomes the real model, plus the machinery. The pattern works, slowly, expensively, and nobody can say precisely when it went wrong.

Implementation patterns

• Write the preconditions down for the pattern being considered — the description will not contain them, so they must be derived from the mechanism.
• Check each against the current situation with evidence, not intuition.
• Identify which preconditions are absent but achievable, and count achieving them as part of the pattern's cost. Cells require automation maturity; a mesh requires a team to run it; contract testing requires consumers who participate.
• Identify which are absent and unachievable, which is a rejection.
• Check the scale distance. A pattern from an organisation three orders of magnitude larger frequently addresses a problem you will not have, at a cost you cannot amortise.
• State what the pattern is protecting against and confirm that risk is present. A pattern with no corresponding risk is pure cost.
• Record the audit in the decision record, so a later reader can check whether the preconditions still hold — which converts the pattern choice into a monitorable position.

Industry example

The Prime Video pipeline case is a precondition failure read backwards. Function-per-step decomposition assumes steps that are not chatty and payloads that are small; that pipeline had frame-granular work with large intermediate data, so the pattern's preconditions were absent and the cost fell on orchestration and transfer rather than compute.

The subsequent public reading — "microservices are a mistake" — is the same error in the opposite direction: generalising a precondition failure into a verdict on the pattern. The transferable finding is the precondition, not the conclusion, which is precisely what a precondition audit is designed to surface before the fact rather than after.

Failure scenarios

• Adopting a pattern because a large organisation uses it, without the scale, workload or team that made it appropriate.
• Preconditions absent and unacknowledged, so their cost is discovered as an ongoing operational burden.
• Preconditions treated as achievable without costing them.
• Rejecting a pattern because a famous post criticised it, in a context where the criticism does not apply.
• Auditing everything, which is its own paralysis — the audit belongs on significant and irreversible choices.
• The audit performed once and never revisited, when preconditions change over time in both directions.
• Preconditions stated so loosely that any situation satisfies them.

Trade-offs

The audit costs time on every significant pattern decision, and applied indiscriminately it slows the team for no benefit — most pattern choices are reversible and cheap, and for those the correct response is to try it rather than to analyse it.

It also requires understanding the mechanism well enough to derive the preconditions, which is a real skill and cannot be looked up. An audit performed by someone who knows only the pattern's shape produces a list of plausible-sounding conditions that miss the binding one.

The trade is analysis time and required depth against the risk of importing an architecture suited to someone else's problem. Spend it on the decisions that are expensive to reverse, and for the rest, rely on the faster instinct — which is what pattern matching is for.

Interview question

"Someone proposes we adopt cell-based architecture. Without telling me whether that is right or wrong, tell me what it assumes about our organisation — then tell me which of those assumptions you would check first and how."