When to Split a Monolith: A Decision Framework

Split when you have **at least two** of these:

1. **Independent scaling needs** — One component needs 10x the compute of others. 2. **Independent deploy cadence** — One team ships daily, another ships monthly. 3. **Fault isolation requirements** — A crash in module A must not take down module B. 4. **Technology heterogeneity** — Module A needs Python ML, module B needs Go for throughput.

**Don't split** for: - "Clean architecture" — a well-structured monolith is cleaner than a distributed mess. - Team size alone — Conway's Law matters, but premature splitting creates coordination overhead that slows small teams. - Resume-driven development.

The first split should be at a **natural seam** — usually the data boundary where two modules share the fewest tables.