SA-201a · Module 2

Architecture Anti-Patterns

3 min read

Anti-patterns are architecture decisions that look reasonable at the time and create compounding problems later. They are not mistakes in the conventional sense — they are traps. The architect who has seen them before recognizes them on approach. The architect who has not walks into them confidently and discovers the cost six months later.

  1. The Distributed Monolith Microservices that must be deployed together, share a database, or break when any one of them fails. All the complexity of microservices with none of the benefits. The symptom: you cannot deploy a single service without coordinating with three other teams. The cause: service boundaries were drawn around code modules, not bounded contexts.
  2. The Golden Hammer Using the same pattern or technology for every problem. "We use Kafka for everything." "Every service is a Lambda function." The symptom: the architecture fights the problem instead of fitting it. The cause: familiarity masquerading as analysis. Every technology has a sweet spot. Outside that sweet spot, it is the wrong tool.
  3. The Big Ball of Mud An architecture with no discernible structure — components call each other arbitrarily, data flows in every direction, and nobody can draw the system diagram. The symptom: every change requires reading the entire codebase. The cause: accumulated decisions without architectural governance. The Technical Debt Ledger catches this before it becomes irreversible.
  4. The Premature Optimization Building for scale, resilience, or performance that the evidence does not justify. Caching layers for twenty users. Message queues for synchronous workflows. Kubernetes for a single-container application. The symptom: more time maintaining infrastructure than building features. The cause: architectural ego — designing for the resume instead of the requirement.

Do This

  • Review every architecture decision against known anti-patterns before committing
  • Ask: "are we doing this because the evidence supports it or because we are comfortable with it?"
  • Use the Technical Debt Ledger to track shortcuts so they do not accumulate into anti-patterns

Avoid This

  • Assume anti-patterns only happen to other teams — they happen to every team that stops questioning its assumptions
  • Continue with a pattern after recognizing it is an anti-pattern because "we are too deep to change" — the cost of continuing always exceeds the cost of correcting
  • Diagnose anti-patterns without proposing the correction — identification without remediation is observation, not architecture