architecture-anti-patterns

name	architecture-anti-patterns
description	Identify and avoid common architectural mistakes. Recognize patterns of failure. Use when reviewing designs or learning from mistakes.

Architecture Anti-Patterns

Recognize and avoid common architectural mistakes that lead to fragility, complexity, or failure.

Context

You are reviewing an architecture and want to spot common anti-patterns. Patterns of failure repeat across organizations. Learn them, recognize them, guide teams away from them.

Domain Context

Based on architecture and design anti-patterns research:

• God Object: One class/service responsible for too much. Hard to change, test, understand.
• Big Ball of Mud: No clear architecture. Code accretion with no structure. Hard to modify without breaking things.
• Circular Dependency: A depends on B, B depends on A. Can't use A without B, vice versa. Breaks modularity.
• Database as Integration Point: Services share database schema. Schema changes break all services. No independence.
• Premature Optimization: Design for 10x scale when you have 1x. Overcomplex, unmaintainable.

Instructions

1. Common Anti-Patterns and Recognition:

   • Monolith Bloat: Hundreds of thousands of lines in one service. Deploys take 30 min. Hard to test. Fix: decompose into services by business domain.
   • Tight Coupling: Service A calls Service B calls Service C synchronously. Cascade failure: A down → B unavailable → C affected. Fix: async, timeouts, circuit breakers, fallbacks.
   • No Logging/Monitoring: Don't know what's happening in production. Outage takes hours to debug. Fix: structured logging, metrics, distributed tracing, alerts.
   • Cache Invalidation Chaos: Cache stale data, inconsistency everywhere. Fix: cache strategy with TTL, event-driven invalidation, don't cache mutable shared state.