anti-patterns

# SDLC anti-patterns to reject Reference catalogue. Cite the anti-pattern by name when blocking a proposal — gives the user a clear vocabulary to discuss the issue. ## Architecture anti-patterns ### A-1. God service **Smell:** One service does auth, billing, search, file storage, and email. **Why bad:** Single deploy unit, single point of failure, every team touches it, change velocity drops over time. **Fix:** Split by business capability (DDD bounded context). ### A-2. Distributed monolith **Smell:** 12 microservices but they share a database and deploy together. **Why bad:** All cost of distributed (latency, eventual consistency, ops overhead) with none of the benefits (independent deploy, isolation). **Fix:** Either truly separate (own DB, own deploy pipeline) or merge. ### A-3. Synchronous chains **Smell:** Request → Service A → Service B → Service C → Service D. **Why bad:** Compound failure probability, p99 latency adds up. **Fix:** Async with events, or co-locate hot path. ### A-4. Premature optimization **Smell:** Custom Redis Lua scripts, hand-tuned binary protocols, before the first paying user. **Why bad:** Complexity cost paid up front, never recouped. **Fix:** Start simple. Optimize when you have load data. ### A-5. Resume-driven development **Smell:** "Let's use Kubernetes / GraphQL / event sourcing / DDD" with no current pain it solves. **Why bad:** Optimizes for engineer's resume, not user's outcome. **Fix:** Ask "what's the simplest thing that could w...