05 — Library · 22 anti-patterns

Anti-patterns

Recurring architecture mistakes: what you see, what they cost, and what to do instead.

Search anti-patternsSort

Anti-patterns

Showing 9 of 22 anti-patterns

AP-200
Alert Fatigue
Delivery & Operations
On-call engineers receive hundreds of alerts a week, most of them noise or symptoms of the same cause, and learn to acknowledge without reading. Real incidents are found by customers first.
Costs · Response slows, important pages are missed, and the on-call rotation burns people out.
Instead · Alert on user-facing symptoms against service level objectives, make every page actionable, route the rest to dashboards or tickets, and review alert volume as an operational metric.
Cured by · SLO and Error Budget,Distributed Tracing
Terms · Service Level Objective,Observability
Reference ↗
AP-140
Anemic Domain Model
Application
Domain objects are bags of getters and setters with no behavior, while all business rules live in service classes that manipulate them. The same rule is checked in several places, slightly differently.
Costs · Rules scatter and drift, invariants are easy to bypass, and the code pays for an object model without gaining the encapsulation that justifies one.
Instead · Move rules into the entities and aggregates that own the data, keep services thin and focused on coordination, and keep infrastructure concerns outside the domain core.
Cured by · Aggregate,Bounded Context,Hexagonal Architecture
Terms · Domain-Driven Design,Bounded Context
Reference ↗
AP-100
Application-Named Capabilities
Capability Modeling
Capabilities carry system or product names, such as CRM, ERP Finance or Data Lake, or exist mainly to give each application a box. Replacing a system would mean renaming the capability.
Costs · The map cannot show overlap or gaps in the application portfolio, because it is the portfolio. Rationalization and vendor-neutral planning have nothing stable to compare against.
Instead · Name the business ability the system supports, such as Customer Relationship Management becoming Account Management, and record which Business Applications realize each capability as a separate mapping.
Terms · Business Capability,Business Application,Application Portfolio,Application Rationalization
AP-010
Big Ball of Mud
Application
A system with no discernible structure: modules call each other freely, data is shared through globals or common tables, and nobody can draw its components without caveats. Every change touches several unrelated places and needs the one person who remembers why.
Costs · Change gets slower and riskier every quarter, onboarding takes months, and the system cannot be split, scaled or replaced in parts because nothing has a boundary to cut along.
Instead · Find the domains hiding in the code and draw explicit module boundaries around them, enforce those boundaries with checks in the build, and extract or replace pieces one boundary at a time.
Cured by · Modular Monolith,Bounded Context,Fitness Functions,Strangler Fig
Terms · Monolith,Technical Debt,Bounded Context
Reference ↗
AP-190
Big-Bang Rewrite
Application
A legacy system is to be replaced in one cutover after a multi-year rebuild. The old system keeps changing meanwhile, the new one chases it, and go-live keeps slipping.
Costs · Value arrives only at the end, if at all; risk concentrates in one cutover; and hidden behavior of the old system is discovered in production.
Instead · Replace the system piece by piece behind a routing layer, move one capability or user group at a time, and retire old parts as each new one proves itself in production.
Cured by · Strangler Fig,Anti-Corruption Layer,Feature Flags
Terms · Technical Debt,Application Rationalization
Reference ↗
AP-110
Boiling the Ocean
Capability Modeling
A capability modeling effort that aims to reach L4 or L5 across the whole enterprise before anyone uses it. Workshops run for months, the model grows to thousands of nodes, and no decision has used it yet.
Costs · Sponsors lose patience before value appears, detail goes stale faster than it is written, and the depth is inconsistent where enthusiasm ran out.
Instead · Build L1 and L2 across the enterprise first, use them for a real decision, and deepen to L3 or below only where a specific investment, rationalization or risk question needs it.
Terms · Capability Map,Capability Level,Capability Heat Map
AP-130
Chatty Services
Integration
A single user action fans out into dozens of small remote calls, often one per field or child record, and page times grow with the size of the data rather than the work done.
Costs · Latency and failure probability multiply with each round trip, network and gateway costs climb, and the services are coupled at a fine grain that makes change hard.
Instead · Design coarser operations around what callers need, batch reads, aggregate for each client in a dedicated layer, cache stable data, and revisit boundaries that force constant cross-service calls.
Cured by · Backend for Frontend,Scatter-Gather,Cache-Aside,Bounded Context
Terms · API,Microservice
Reference ↗
AP-220
CMDB Dumping Ground
Data
Everything discovery finds is loaded into the CMDB with no class model, owner or stated purpose. Duplicate and stale Configuration Items pile up, relationships are missing, and teams keep their own lists instead.
Costs · Nobody trusts it, so impact analysis, change risk and service mapping fall back to tribal knowledge, and the platform's value case erodes while license and discovery costs continue.
Instead · Start from the processes the CMDB must serve, define the classes and relationships they need, assign owners and health checks for each class, and load only data with a known source and consumer.
Terms · CMDB,Configuration Item,Data Governance,Application Service
AP-160
Data Swamp
Data
A data lake where datasets land without owners, schemas, quality checks or lineage. Analysts find several copies of the same table and cannot tell which is current or correct.
Costs · Trust collapses, so teams build private extracts and the platform pays for storage that answers nothing. Sensitive data hides in places no one governs.
Instead · Require an owner, schema and description for each dataset, separate raw from curated layers, record lineage, and publish trusted datasets as products with quality checks consumers can see.
Cured by · Medallion Lakehouse Layering,Data Mesh,Schema Registry
Terms · Data Product,Data Lineage,Data Governance
AP-020
Distributed Monolith
Application
Services that are deployed separately but must be released together, share a database or a library of domain types, and call each other synchronously in long chains. One service down takes the whole journey down.
Costs · It carries the network, operational and debugging cost of microservices with none of the independence, so teams pay twice and still coordinate every release.
Instead · Redraw service boundaries around business domains, give each service its own data, prefer events over synchronous call chains, and merge services back into a modular monolith where independence is not needed.
Cured by · Bounded Context,Modular Monolith,Domain Events,Publish-Subscribe
Terms · Microservice,Monolith,Bounded Context
AP-150
God Service
Application
One service or application accumulates responsibilities across many domains, sits in the middle of most integrations, and has the longest backlog and the most teams waiting on it.
Costs · It becomes the bottleneck for change and the largest single point of failure, and its owning team cannot keep up with the domains it now carries.
Instead · Identify the domains inside it, assign each to a clear owner, and move responsibilities out one bounded context at a time, routing traffic to the new home as each piece is ready.
Cured by · Bounded Context,Strangler Fig,Anti-Corruption Layer
Terms · Bounded Context,Technical Debt
AP-050
Golden Hammer
Architecture Practice
One familiar platform, product or pattern is applied to every problem: workflow tools used as databases, a low-code platform for real-time systems, or events everywhere because the last project used them.
Costs · Solutions fit the tool rather than the need, workarounds pile up, and the organization stops noticing options that would be cheaper or simpler.
Instead · State the problem and its quality requirements before naming a solution, compare at least two credible options in a recorded decision, and keep a technology standard that says where each tool fits and where it does not.
Cured by · Architecture Decision Records
Terms · Architecture Decision Record,Technology Standard
AP-060
Ivory Tower Architecture
Architecture Practice
Architects produce principles, standards and target states without working with the teams that build and run the systems. Reviews happen late, decisions arrive as edicts, and delivery teams route around the function.
Costs · Guidance is ignored or followed in form only, the architecture team loses credibility, and the real architecture is decided by whoever ships first.
Instead · Put architects alongside delivery teams, make decisions in the open with recorded reasoning, turn standards into automated checks where possible, and judge the practice by outcomes in production, not documents.
Cured by · Architecture Decision Records,Fitness Functions,Inner Source
Terms · Architecture Review Board,Architecture Principle,Fitness Function
AP-080
Org-Chart Capability Map
Capability Modeling
The capability map's top level mirrors the current departments, and capabilities are named after teams, so the same ability appears under two divisions and shared abilities have no home.
Costs · The map breaks at the next reorganization, hides duplication across business units, and cannot show where two groups invest in the same ability.
Instead · Describe what the business does, independent of who does it today. Group capabilities by business purpose, keep one place for each, and map organization units onto capabilities as a separate relationship.
Terms · Business Capability,Capability Map,Operating Model
AP-040
Point-to-Point Spaghetti
Integration
Every application integrates directly with every other through bespoke file drops, scripts and one-off interfaces. The integration inventory is a guess, and the same customer record is mapped five different ways.
Costs · Interfaces grow with the square of the application count, each with its own failure mode, and retiring an application means finding every hidden consumer first.
Instead · Standardize a small set of integration styles, publish shared business events and APIs with registered schemas, and route new and rebuilt interfaces through them while keeping an inventory of what remains.
Cured by · Publish-Subscribe,API Gateway,Schema Registry,Anti-Corruption Layer
Terms · Integration Pattern,API,Event-Driven Architecture
AP-090
Process Posing as a Capability
Capability Modeling
Capability names are verbs or steps, such as Approve Invoice or Onboard Customer Step 3, and children follow a sequence with starts, ends and hand-offs. The map reads like a process flow.
Costs · The map changes every time a process is redesigned, overlaps with the process model, and loses the stable frame that investment and application mapping depend on.
Instead · Name capabilities as nouns for an ability the business has, such as Accounts Payable, and keep sequence in process and value stream models that use those capabilities.
Terms · Business Capability,Business Process,Value Stream
AP-120
Resume-Driven Design
Architecture Practice
Technology choices that track what is fashionable or career-enhancing rather than what the problem needs: Kubernetes for a small internal app, a new database per service, or the latest framework in every project.
Costs · Operating cost and skills demand rise without matching benefit, and the system outlives the enthusiasm of the people who chose its stack.
Instead · Tie each technology choice to a stated requirement in a recorded decision, prefer approved standards unless a gap is shown, and count operating and staffing cost in the comparison.
Cured by · Architecture Decision Records
Terms · Architecture Decision Record,Technology Standard,Total Cost of Ownership
AP-210
Retry Storm
Delivery & Operations
When a dependency slows down, every caller retries immediately and repeatedly, often at several layers at once, so traffic to the struggling service multiplies just as it can least handle it.
Costs · A brief slowdown becomes an outage that persists after the original fault clears, and recovery requires shedding load by hand.
Instead · Retry only idempotent calls, with capped, jittered backoff and a deadline, retry at one layer only, and use circuit breakers and rate limits so callers back off as a group.
Cured by · Retry with Backoff,Circuit Breaker,Rate Limiting
Reference ↗
AP-030
Shared Database Integration
Integration
Several applications read and write the same database tables directly to exchange data. Schema changes need sign-off from every team, and no one can say which application owns a given column.
Costs · The schema freezes, ownership blurs, and a change made safely for one application silently breaks another. Replacing any one application means untangling all of them.
Instead · Give each dataset one owning application, expose it through an API or published events, and use change data capture or an outbox to feed others while consumers migrate off direct table access.
Cured by · Bounded Context,Change Data Capture,Transactional Outbox,Anti-Corruption Layer
Terms · System of Record,Integration Pattern,API
Reference ↗
AP-070
Shelfware Architecture
Architecture Practice
Target-state diagrams, reference architectures and capability maps that were produced once, presented and never opened again. Nobody can say which decision they informed, and they no longer match what is running.
Costs · The effort is sunk, and stale artifacts mislead the people who do find them. Leadership learns that architecture work produces documents rather than decisions.
Instead · Start each artifact from a decision someone must make, keep it in a maintained repository with an owner and review date, and retire what no longer drives a decision.
Cured by · Architecture Decision Records,Fitness Functions
Terms · Architecture Repository,Target State,Roadmap
AP-180
Snowflake Servers
Delivery & Operations
Servers configured by hand over years, each slightly different, that nobody dares to rebuild. Patching is manual, and a failed host takes days to recreate from memory and old tickets.
Costs · Recovery is slow and uncertain, drift causes failures that only happen in one environment, and security patches lag because every change is a risk.
Instead · Define servers and their configuration as code, rebuild rather than modify them, and replace hosts regularly so rebuilding is routine and proven.
Cured by · Infrastructure as Code,Immutable Infrastructure
Terms · Infrastructure as Code
Reference ↗
AP-170
Spreadsheet System of Record
Data
A critical business list, such as pricing, entitlements or the application inventory, lives in a spreadsheet that is emailed around or edited by many people, with other systems loading from whichever copy is nearest.
Costs · Versions diverge, edits have no audit trail or validation, and the business depends on one person's file that no backup, access control or integration standard covers.
Instead · Name the system that should own the data, move the master copy there with validation and access control, and keep spreadsheets as views or input forms that feed it rather than as the record.
Terms · System of Record,Master Data,Data Governance

Anti-patterns

Anti-patterns

Alert Fatigue

Anemic Domain Model

Application-Named Capabilities

Big Ball of Mud

Big-Bang Rewrite

Boiling the Ocean

Chatty Services

CMDB Dumping Ground

Data Swamp

Distributed Monolith

God Service

Golden Hammer

Ivory Tower Architecture

Org-Chart Capability Map

Point-to-Point Spaghetti

Process Posing as a Capability

Resume-Driven Design

Retry Storm

Shared Database Integration

Shelfware Architecture

Snowflake Servers

Spreadsheet System of Record