practice

Pattern Recognition

Recognising that a new problem is an instance of a known one — the main source of an experienced architect's speed, and of their characteristic errors.

experiencepatternsjudgementtransferbias

Definition

The ability to see that this problem resembles one you have seen before, and to bring the accumulated knowledge about its consequences and failure modes.

Why it 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, this is speculative generality — and immediately have access to the usual failure modes, the usual remedies and the usual 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 patterns worth being able to recognise 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. Every cost, no benefit.
  • The cascade — a slowdown exhausting pools and propagating up the call graph.
  • Speculative generality — an abstraction for a variation that has not appeared.
  • The unowned component — no team, no patches, discovered in an incident.
  • The invisible constraint — a logical resource limit nobody monitors.

The characteristic failure

Pattern matching on surface features. Two systems that look similar can have entirely different constraints. "This is like the system we built at my last company" is a hypothesis, not a conclusion, and it is the most common way experienced architects get things wrong.

The corrective habit: name the pattern, then check whether the conditions that made it apply are actually present. If they are not, discard it and reason from first principles.

Building it deliberately

  • Read incident reports, especially other organisations' published ones. They are the densest source of failure patterns available.
  • Work on different systems, not the same one for a decade. Depth in one context produces patterns that do not transfer.
  • Study the architectural pattern catalogue — circuit breaker, bulkhead, saga, outbox, strangler fig — because the names carry accumulated knowledge about consequences.
  • Write down what you were wrong about, which is how the recognition gets calibrated.

Interview question

"Describe a time you recognised a familiar pattern in a new problem — and a time that recognition was wrong."