Pattern recognition is what makes an experienced architect fast. What is its characteristic failure and how do you guard against it?

What is being tested

Whether you know the specific way experience misleads.

Why pattern recognition is the main source of speed

An experienced architect does not analyse every problem from scratch. They recognise the shape — this is a fan-out problem, this is a dual-write problem, this is a distributed monolith — and immediately have access to the usual failure modes, remedies and trade-offs.

That recognition is what experience actually buys, and it is why the same problem takes an hour for one person and a week for another.

The failure

"This is like the system we built at my last company." It looks similar and the constraints differ — in scale, team size, regulatory context, existing estate, or the shape of the workload.

Reasoning by analogy from a published architecture is the same error. A company's design reflects their scale, history and team structure; adopting it without those conditions is how organisations end up operating machinery for a problem they do not have.

The guard

Name the pattern, then check whether the conditions that made it apply are actually present.

State explicitly: "this looks like X. X applies when A, B and C are true. Are they?" If they are not, discard it and reason from first principles.

That takes two minutes and prevents the most expensive category of experienced-architect mistake.

The patterns worth recognising instantly

• Dual write — a database update and an event publish that are not atomic. Silent data loss.
• Fan-out with a skewed distribution — the celebrity problem; head and tail need different designs.
• Distributed monolith — services that must deploy together.
• The cascade — a slowdown exhausting pools and propagating up the call graph.
• Speculative generality — an abstraction for a variation that has not appeared.
• The invisible constraint — a logical resource limit nobody monitors.

Building it deliberately

Read incident reports, especially other organisations' published ones — the densest available source of failure patterns. Work on different systems rather than one for a decade, since depth in one context produces patterns that do not transfer. Write down what you were wrong about, which is how the recognition gets calibrated.