Precondition Check

Pattern recognition is fast and usually right: most problems are instances of something solved before. Its failure mode is applying a pattern whose preconditions do not hold, which is invisible because the shape fits while the assumptions do not.

Every pattern encodes assumptions. A saga assumes compensations exist. Optimistic concurrency assumes conflicts are rare. Caching assumes read-heavy access with tolerable staleness. Sharding assumes a key that distributes and matches the invariants. Event sourcing assumes history is the truth.

The check is: do this problem's conditions match those assumptions? Where they diverge is exactly where the pattern will fail.

Why it matters

It combines the speed of pattern reuse with the safety of first-principles reasoning, at a cost of about ten minutes. Full derivation from first principles is slow and its own failure mode is re-deriving something well known, badly — so neither approach alone is right.

Implementation patterns

• Write down the pattern's assumptions explicitly before applying it. Most are unstated in the literature and become obvious once asked for.
• Compare each against the problem's actual conditions, using evidence where available — the conflict rate, the read-write ratio, the staleness tolerance, the key distribution.
• Treat a divergence as a design input rather than as a disqualification. A violated assumption may be fixable, may be tolerable, or may change the design — and knowing which is the point.
• Go fully to first principles only when the assumptions are violated in a way that matters and the cost of being wrong is high. Both conditions, not one.
• Record the check in the decision record, since a future reader needs to know which assumptions the design rests on.

Industry example

A ten-minute grocery delivery promise looks like standard order fulfilment and differs in one assumption: the physical world does not roll back. A dispatched rider is a cost incurred; a picked item is stock committed; compensation is a refund or a wasted trip rather than a database operation.

That single divergence produces a different design — strong consistency at the point of commitment, reversible steps ordered before irreversible ones, safety stock rather than exact counts — none of which the standard pattern would have suggested, and all of which is obvious once the assumption is named.

Failure scenarios

• Cargo-culting: applying a well-regarded pattern without checking preconditions.
• Contrarianism: rejecting established solutions to derive a novel one, usually slower and worse and frequently motivated by interest rather than by the problem.
• Checking the assumptions after implementation, when the divergence is expensive.
• Assuming a divergence disqualifies the pattern, when it may simply need adaptation.

Trade-offs

The check costs time on every pattern application, most of which will pass — so it is overhead in the common case. It also requires knowing the pattern's assumptions, which is itself expertise.

The mitigation is proportionality: apply it where the decision is expensive to reverse and skip it where it is not. A caching strategy can be tried; a partition key cannot.

Interview question

"You are about to use a saga for a multi-step process. List the assumptions a saga makes, and tell me which one you are least sure holds here."