Anti-Pattern Catalog — Reverse Lookup Before You're Stuck

About this article

This article is the first installment of the “Appendix” category in the Architecture Crash Course for the Generative-AI Era series, covering the anti-pattern catalog.

The “common misconceptions” and “common failures” from each article are reorganized here as a cross-domain reverse-lookup catalog. The architect’s job is more about avoiding fatal mistakes than picking the perfect option, so this article is designed as a “notice it before you’re stuck” early-warning device. When something feels off, look up the matching category here.

A full list of all Appendix articles is available at the following page.

Appendix — Article Index — Architecture Crash Course for theen.senkohome.com/arch-intro-index-appendix/

What are anti-patterns, anyway?

Think of traffic-accident cause patterns. “Distracted driving,” “speeding,” “running a stop sign” — accident causes are not new every time; the same patterns repeat over and over. Knowing the patterns lets you spot danger and dodge it in advance.

Anti-patterns are the architecture version of an accident-cause catalog. They categorize “design decisions you must not make” that have been observed repeatedly in past projects — a collective body of wisdom for not repeating the same mistakes.

Without knowing anti-patterns, you step on the same landmines others have already stepped on. Avoiding fatal mistakes is at least as important as pursuing the right design.

Why you need to learn anti-patterns

Avoiding “fatal mistakes” is more effective than memorizing the right answers

Architecture choices are infinite, but fatal-mistake patterns are finite and repeat. Memorizing every correct answer is impossible, but holding on to “never do this” dramatically raises the quality of design reviews.

”Plausible-sounding decisions” are the most dangerous

Many anti-patterns look rational at first glance. “Microservices scale better,” “NoSQL is faster,” “the latest tech is more productive” — each can be right or wrong depending on context. Learning anti-patterns builds the habit of checking preconditions.

They function as a team’s shared vocabulary

When you can call out “that’s a Golden Hammer” or “we’re turning into a Big Ball of Mud” by pattern name, design reviews and discussions become vastly more efficient. Sharing abstract concerns through concrete archetypes raises the entire team’s design capability.

Architecture-wide traps

Decision-making mistakes common across all domains. Less about specific tech selection, more about posture toward design. These show up in nearly every failed project.

“Documented rationale” beats “technically correct” in long-term operations.

Infrastructure / deployment traps

Typical mis-selections around cloud, servers, and networking. The root cause is often “just copying a megacorp.” Misjudging your scale and phase is fatal.

Doing “AWS Certified-grade” design at a startup melts away product-development time.

Data traps

Typical mis-selections in datastore selection and database operations. Unlike applications, data cannot be rebuilt, so failures here echo for five years.

Failures in data architecture are about 5x heavier than failures in application architecture — because rebuilding is not an option.

Application traps

Typical errors in code design, modularization, and error handling. They run in the short term, so they’re easy to miss, and slowly suffocate maintainability over months and years.

“Working but unmaintainable code” is the act of forcing technical debt onto everyone but yourself.

Frontend traps

Frontend-specific mis-selections and implementation errors. Many of these directly hit security and performance, affecting user trust.

Frontend anti-patterns are directly visible to users, so the cost is high.

Security traps

The defining feature of typical security architecture errors is that they are not recoverable. Once data leaks, no after-the-fact mitigation puts it back.

Security costs 100x more after an incident than during initial setup. Standard equipment from day one.

Monitoring / operations traps

Anti-patterns that surface in operations. Things “appear to be working” for a long time, then erupt all at once during an incident.

“Running” and “observable” are not the same thing. What’s not visualized may as well not exist.

Process / organization traps

Anti-patterns at the decision-making and org-running level — upstream of any tech choice. Trying to solve these with technology fails. They have to be treated as people problems.

The most common failure mode, oddly, is getting the tech right but losing on process.

AI-era specific traps

Anti-patterns that have surfaced recently, around AI-driven development and AI-as-default operations. These need a viewpoint that classical design doesn’t have, and accumulate as debt if you don’t recognize them.

The AI-era design principle places “can AI fluently write and read this?” at the center of selection.

Major incident damages by anti-pattern

The cost of anti-patterns is a scale that cannot be ignored when measured in dollars. The legendary cases:

A single anti-pattern triggering hundreds of millions to billions of dollars in damage is real, recurring history. “Boring operations are the strongest defense” and “design luxury earned only after the hypothesis pays off” are the historical refrains shaping the industry’s intuition.

Common root causes

These anti-patterns share common root causes. Surface symptoms differ but trace back to the same handful of starting points, so naming the root makes prevention easier.

90% of anti-patterns reduce to getting scale and phase wrong or skipping documentation.

Looking back at burning projects, the failure causes are remarkably similar. “We wanted to use new tech,” “We wanted it to look cool,” “We wanted to learn” — designs born from these three motives almost always break down somewhere. By contrast, the “boring but it works” designs frequently keep humming for five years. Half of the architect’s job is fighting your own desires, and the other half is finding the courage to accept being boring.

| “New tech is better” blind faith | Options with thin information and no operational track record leave you stranded during incidents; boring tech wins in five years | | “Read the code” documentation abandonment | Without ADRs, the reasoning vanishes in three years and the same mistakes repeat |

AI decision axes

1. Defuse the fatal landmines first — security, data, and operations are unrecoverable.
2. Match scale and phase — copying megacorps and copying startups are both dangerous.
3. The courage to choose boring — prefer options with 5 years of operational track record.
4. Document the rationale — leave why-we-chose in ADRs.

AI-recommended architectures contain antipatterns

If you ask AI “propose a modern architecture”, it may recommend complex configurations like microservices, Kubernetes, event-driven, and CQRS. This is because the training data contains a high proportion of case-study articles and conference materials from large enterprises, so AI tends to return “idealized answers” without considering the questioner’s context (team size, budget, operational capacity).

If a 10-person team follows AI’s recommendation and splits into microservices, they will repeat the same failures as Segment and Uber described in this article. When receiving proposals from AI, you need the habit of explicitly stating your team size, budget, and operational capacity, then asking back “is anything excessive for this scale?”

AI’s answers change dramatically depending on how you phrase the question. Asking for “the best” or “modern” returns over-engineered answers; asking for “the simplest setup a 5-person team can operate” returns practical answers. Be aware that prompt phrasing directly affects antipattern avoidance.

”AI-delegated” is itself becoming a new antipattern

With the spread of AI coding tools, cases are emerging where review is skipped under the judgment “AI wrote it, so it’s OK.” This is a new form of antipattern. AI-generated code returns statistically plausible patterns, but it does not automatically account for project-specific constraints (consistency with existing DB structure, team naming conventions, security policies, etc.).

Especially dangerous is adopting AI-generated design decisions (DB selection, authentication method, caching strategy, etc.) without rationale, simply because “AI said so.” Design decisions always require a reason for “why this choice was made”, and “AI recommended it” does not qualify as a reason.

If you have the habit of recording decision rationale in ADRs, even AI proposals force you to articulate “why we adopted this”, preventing uncritical adoption.

Author’s note — winners who picked “boring tech”

Stack Overflow is a Q&A site with over 100M monthly hits, and its 2016 published numbers showed it ran on just 9 servers at the time. The stack was extremely conservative — .NET + SQL Server + Redis. No microservices, no NoSQL. CTO David Fullerton has publicly stated “we deliberately choose boring technology”, and it remains a frequent live example of Etsy engineer Dan McKinley’s 2015 essay “Choose Boring Technology.”

By contrast, Uber split into 2,200+ microservices in the mid-2010s and then ran into incident isolation becoming impossible, deteriorating developer experience, and proliferating duplicate functionality. In the 2020s they announced “DOMA” (Domain-Oriented Microservice Architecture), a domain-based reconsolidation. It is frequently cited as “the post-mortem on going to maximum decomposition.” Those who chose boring tech are still humming five years later; those who chased trends are still busy with consolidation projects five years later. This contrast suggests many anti-patterns are the result of paying for personal desires with organizational assets.

Self-check checklist

Use this list to confirm whether your project has stepped into anti-pattern territory. Hitting even one is reason to revisit the relevant reference.

• Switched to microservices, but the team is < 30 people.
• Using K8s, but no dedicated SRE.
• Multi-cloud setup with no clear rationale.
• Running analytical queries on the production DB.
• Hand-rolled auth and session management.
• Storing JWT in localStorage.
• MFA not enforced for all users.
• Logs not structured.
• No SLO defined.
• No ADRs being written.

Summary

This article covered the anti-pattern catalog end-to-end — cross-domain, 9 categories, major-incident damages, common root causes, and a self-check.

Defuse fatal landmines first, match scale, stay boringly consistent, document the rationale. That is the realistic answer to anti-pattern avoidance in 2026.

The next article covers the “best-practice catalog” — the mirror image: the iron-clad first-pick options when in doubt, organized by domain.

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.