---
title: "Architecture anti-patterns and failure smells"
chapter: "27"
---

# Architecture anti-patterns and failure smells

An anti-pattern is a recurring response that looks attractive but produces harmful consequences in context. Names are useful only when they lead to diagnosis and a safer migration.

## Core ideas and patterns

| Idea | What it solves | Cost, limit, or warning |
|---|---|---|
| **Big ball of mud** | Signals boundaries and ownership have eroded | A rewrite without domain learning repeats it |
| **Distributed monolith** | Services deploy or fail together despite network boundaries | More infrastructure does not create autonomy |
| **Shared database** | Lets services bypass owned contracts | Sometimes valid for modules, dangerous for claimed autonomy |
| **Chatty interface** | Requires many fine-grained remote calls | Latency and partial failure multiply |
| **God service/object** | Centralizes unrelated policy and knowledge | Splitting by method count misses domain cohesion |
| **Golden hammer** | Uses one familiar technology for every force | Standardization can hide mismatch |
| **Resume-driven architecture** | Optimizes learning novelty over system need | Long-term operational cost remains |
| **Vendor lock-in panic** | Builds abstractions for imaginary portability | The abstraction can cost more than migration |
| **Cargo-cult microservices** | Copies topology without its forces | Teams inherit distributed complexity |
| **Lava flow** | Leaves dead or half-understood paths in place | Removal requires usage evidence and ownership |
| **Architecture astronaut** | Creates abstractions far above concrete needs | Vocabulary grows while delivery slows |
| **Single point of human failure** | Depends on undocumented expert knowledge | Redundancy must include people and procedure |

## How to apply it

Describe the observed consequence before applying a label. Map dependencies, co-change, failure propagation, ownership, data access, and release coordination. Identify the smallest boundary or contract that can be recovered. Migrate with characterization tests, telemetry, strangling, and explicit deletion.

## Evidence, not opinion

Measure cross-service release coupling, cyclic dependencies, shared-table access, remote call count, incident blast radius, bus factor, unused code paths, and time to understand a change.

## Small example

Ten “microservices” share one schema, release train, library version, and synchronous chain. The corrective goal is independent capability ownership; merging some services may be the fastest path.

## Feynman check

Explain the design to a new engineer without using the pattern names. State the
problem, the forces that conflict, the chosen boundary or mechanism, what can
fail, and the evidence that would prove the choice still works.