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.

flowchart TB
    SYM([Feel the symptom?<br/>Reverse lookup below])
    A[Architecture overall<br/>Over-engineering / Big-bang rewrite]
    I[Infra<br/>Manual deploy / Single AZ]
    D[Data<br/>NoSQL-everywhere / Broken normalization]
    APP[App<br/>God class / Anemic model]
    F[Frontend<br/>SPA-everywhere / CSS-in-JS abuse]
    S[Security<br/>JWT in localStorage]
    O[Monitoring & ops<br/>Flying blind]
    P[Process<br/>Big PRs / Long-lived branches]
    AI[AI era<br/>Custom languages / Generation dump]
    SYM --> A
    SYM --> I
    SYM --> D
    SYM --> APP
    SYM --> F
    SYM --> S
    SYM --> O
    SYM --> P
    SYM --> AI
    classDef root fill:#fef3c7,stroke:#d97706;
    classDef bad fill:#fee2e2,stroke:#dc2626;
    class SYM root;
    class A,I,D,APP,F,S,O,P,AI bad;

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.

Anti-pattern	Symptom	Prescription
Over-engineering (YAGNI violation)	Massive unused features, layers, abstractions	Build only what current requirements need
Jumping on the latest tech	Information thin, easy to get stuck	Prefer options with 2-3 years of operational track record
Reinventing the wheel	Building what an existing product covers	Lean on standard libraries / SaaS
No documentation of decisions	Nobody remembers “why we picked this”	Write ADRs (Architecture Decision Records)
Conclusions without benchmarks	Decided by “feels faster”	Always measure first

“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.

Anti-pattern	Symptom	Prescription
Pointless multi-cloud	IAM, monitoring, IaC duplicated, ops doubled	Lean on a single cloud
Adopting K8s without need	Ops time eats dev time	ECS Fargate / Cloud Run is enough
Premature microservices	Bog down in distributed transactions and network boundaries	Start monolith, split when actually needed
Manual setup without IaC	Environment drift, not reproducible	Manage all resources via Terraform / CDK
RDS not in private subnet	DB exposed to public network	Always private subnet

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.

Anti-pattern	Symptom	Prescription
Running analytical queries on the production DB	Customer-perceived speed degrades	Separate OLTP (operational) and OLAP (analytical) early; build a DWH (Data Warehouse)
Escape into schemaless DBs	Stuck for AI use and analytics later	PostgreSQL + schema definitions
Master data fragmented per department	Customer duplicates, integration impossible	Build MDM (Master Data Management)
Overwrite-update without history	No audit trail, ML modeling stalls	History tables or Event Sourcing
No data quality checks	Inconsistent data poisons analytics	Automate with dbt tests / Great Expectations
Backup-restore never validated	Restore fails on actual disaster	Quarterly restore drills

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.

Anti-pattern	Symptom	Prescription
God classes / God functions	Thousands of lines per file, unclear responsibility	Single Responsibility Principle
Business logic in stored procedures	DB migration impossible, hard to test	Push logic into the application
Swallowing errors (`catch { }`)	Failures don’t surface, deepen	Log + rethrow, or explicit handling
Meaningless naming (`data`, `util`, `manager`)	Code intent unreadable	Name in domain terms
All static methods	Untestable, no DI possible	DI container or constructor injection
Methods returning null	Missed null checks at call sites	Optional / Result types

“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.

Anti-pattern	Symptom	Prescription
Storing JWT (JSON Web Token = signed token containing auth state) in localStorage	Single XSS leaks the token	HttpOnly Cookie + BFF (Backend for Frontend)
CSR for an SEO-critical site	Doesn’t index in search	Use SSR / SSG / ISR
Hand-rolled auth cookies	Vulnerability breeding ground	Delegate to Clerk / Auth.js / Auth0
In-house CSS design system	Hard to hire, learning cost wasted	Tailwind + shadcn/ui
Serving images unoptimized	LCP destroyed, Core Web Vitals tank	CDN transform + WebP / AVIF
Raw React without a meta-framework	Hand-rolled routing, SSR, build	Use Next.js / Astro

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.

Anti-pattern	Symptom	Prescription
Building auth in-house	Holes in password reset, MFA, etc.	Delegate to Auth0 / Cognito / Clerk
Optional MFA	Single password leak, instantly compromised	Mandatory for all users
Password-only auth	One phishing hit and you’re done	Standardize Passkey support
Logging PII in plaintext	Violates data protection law	PII masking + audit
Committing secrets to Git	Leak -> high bills, legal risk	Vault / Secret Manager + pre-commit hook
Still allowing TLS 1.0 / 1.1	Audit-failing	TLS 1.3 mandatory, 1.2 minimum
Trusting “inside the VPN” (perimeter model)	Internal compromise propagates everywhere	Zero Trust, authenticate every request

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.

Anti-pattern	Symptom	Prescription
Alerts firing but nobody watching	Major incidents discovered late	PagerDuty + on-call rotation
Operating without SLOs	Cannot discuss quality numerically	Declare 99.9% availability etc.
Logs not structured	Search and aggregation impossible	Standardize JSON structured logs
No runbook	New hires panic during night incidents	Document procedures for common failures
Skipping postmortems	Same incident keeps repeating	Always record cause and countermeasure post-incident
Direct SSH fixes in production	Changes not reproducible, not auditable	Only via CI/CD pipeline

“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.

Anti-pattern	Symptom	Prescription
No documentation of architectural decisions	Nobody can answer “why?”	Write ADRs
Architect operates in isolation	Idealistic decisions disconnected from reality	Decide together with implementers
Ignoring Conway’s Law	System boundaries don’t match org structure	Reverse-engineer design from team structure
Vendor handoff with no understanding	Nobody internally understands the internals	Buyer must understand the architecture
Big-bang rewrite project	Years and millions wasted on failure	Strangler Fig phased migration
”We won’t know until we try” drift	Cannot estimate, cannot evaluate risk	Enforce PoC -> implementation order

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.

Anti-pattern	Symptom	Prescription
Adopting an in-house framework that AI can’t write	AI productivity boost doesn’t apply	Lean on mainstream frameworks (Next.js, Django, etc.)
Schemaless JSON storage	AI cannot infer the data structure	Make types and schemas explicit
GUI-operation-dependent tools	Cannot delegate operation to AI	Choose tools operable via CLI / API / IaC
No data catalog	RAG and AI agents cannot infer semantics	Maintain metadata and descriptions
Deploying AI-generated code without review	Vulnerabilities and bugs into production	Don’t skip the regular review/test cycle
No vector DB support	Cannot bolt RAG on later	Design assuming pgvector / Pinecone

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:

Case	Year	Anti-pattern	Damage / impact
Knight Capital	2012	Deploy procedure error (one machine got old code)	$440M lost in 45 minutes, company dissolved
Adobe data leak	2013	ECB mode + shared password hint	150M passwords effectively cracked
Dyn DNS attack	2016	IoT botnet (Mirai)	Twitter / GitHub / Netflix offline for hours, 1.2 Tbps DDoS
GitLab DB deletion	2017	rm -rf during on-call + all 5 backup methods broken	Restored from 6-hour-old snapshot, 300GB lost
Equifax data leak	2017	Struts 2 patch left for 2 months	$700M settlement, 147M people leaked
Capital One	2019	IAM over-privilege + WAF misconfig	$80M fine, 100M records leaked
AWS Kinesis outage	2020	Streaming foundation as SPOF	us-east-1 long outage, took out the AWS Console
SolarWinds	2020	Compromise via trusted vendor	18,000 organizations compromised through legitimate channels
Log4Shell	2021	No SBOM	World’s Java apps got a zero-day, impact unknown to many
Facebook 6h outage	2021	BGP misconfig + collocated monitoring	Ad revenue loss > $60M
Meta GDPR fine	2023	EU citizen data sent to US	EUR 1.2B (~$1.3B)
CrowdStrike outage	2024	Update error	Windows endpoints worldwide BSODed; airports, banks, hospitals halted

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.

Root cause	Typical phrase	Countermeasure
Misjudging scale and phase	”Google does microservices, so…”	Judge by your own scale
Blind faith in newness	”It’s the latest, so it must be better”	Weight information density and operational track record
”Build it ourselves to learn"	"It’ll be educational, so we’ll DIY”	Don’t learn in production
Short-term view	”It just needs to work right now”	Evaluate the 5-year debt
Abandoning documentation	”Read the code”	Leave reasoning in ADRs

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.

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.

How to make the final call

The core of the anti-pattern catalog is the mindset of first eliminating fatal mistakes, then optimizing. The gap between merely-good options is usually small, but stepping on a landmine is not recoverable. Over-engineering, chasing the latest, DIY temptation, scale-mismatched architecture, abandoning documentation — these five make up 90% of all incidents. Stack Overflow’s 9-server operation and Basecamp’s monolith persistence demonstrate that the courage to stay boring produces systems that hum for five years.

The other decisive lens is the realization that the industry’s intuitions are formed by hundred-million-dollar failures. Knight Capital’s $440M in 45 minutes, Equifax’s $700M settlement, Meta’s EUR 1.2B GDPR fine — these are how the industry has paid to learn “how much an anti-pattern costs.” Leaning on standards looks unflashy, but it is the strongest defense.

Selection priority

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

“Avoid the landmines, stay boringly consistent.” That is the iron rule for not stepping on anti-patterns.

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.