Understanding Microservices Anti-Patterns
1. Avoiding Distributed Monolith Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | Services tightly coupled; deployed together; share DB; cascading failures |
| Cause | Splitting code without splitting data/ownership |
| Fix | Decompose by business capability; database per service; async events |
2. Avoiding Shared Database Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | Multiple services read/write same tables |
| Problems | Schema changes break everything; coupling; can't scale independently |
| Fix | Owner service exposes API/events; others integrate via API only |
3. Avoiding Chatty Services Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | Single user request → 50+ inter-service calls |
| Causes | Wrong granularity; no aggregation; N+1 across services |
| Fix | Aggregator/BFF; batch APIs; co-locate related capabilities |
4. Avoiding God Service Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | One service owns disproportionate logic / endpoints / data |
| Risks | Bottleneck; single team blocks all changes; high blast radius |
| Fix | Decompose by subdomain; carve out bounded contexts |
5. Avoiding Nanoservice Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | Service so small (1 endpoint) that infra cost > benefit |
| Problems | Operational overhead; latency; deploy complexity |
| Fix | Merge with cohesive sibling; right-size to bounded context |
6. Avoiding Spaghetti Architecture Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | Service graph is a tangled mesh; no clear layers |
| Causes | Ad-hoc evolution; no architecture governance |
| Fix | Define layers (edge / domain / data); enforce dep direction; service catalog |
7. Avoiding Wrong Cuts Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | Decomposed by tech layer (UI, business, data) instead of domain |
| Result | Every change touches all services |
| Fix | Decompose by business capability / bounded context (vertical slices) |
8. Avoiding Synchronous Chains Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | A → B → C → D → E synchronously per request |
| Risks | Latency multiplies; one slow link kills request; cascading failures |
| Fix | Async messaging; CQRS read models; aggregator with parallel fan-out |
9. Avoiding Mega Service Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | A "microservice" with 1M LoC owning many domains |
| Cause | Reluctance to split; team owns too much |
| Fix | Strangler-fig migration; carve out subdomains incrementally |
10. Avoiding Shared Library Overuse Anti-Pattern
| Symptom | Detail |
|---|---|
| Sign | Domain logic in shared lib; lib bump requires N service redeploys |
| Problems | Re-coupling; version skew; release coordination |
| Fix | Limit shared libs to truly stable infra (logging, auth client); push cross-cutting concerns to sidecar/mesh |
Note: Anti-patterns aren't moral failures — most evolve from valid early decisions that didn't scale. Re-evaluate architecture quarterly against these symptoms.