When to Break the Monolith: A Pragmatic Guide
Microservices aren't a destination — they're a tool. Here's the framework I use to help teams decide when decomposition is genuinely worth it.
Few architectural discussions generate more heat than the monolith-vs-microservices debate. On one side: engineers who've suffered through tightly coupled systems that couldn't scale independently. On the other: engineers who've suffered through distributed systems that added enormous operational complexity for little apparent gain.
Both sides are right, and that's the point. The question isn't which is better — it's when does decomposition pay off.
The Case Against Premature Decomposition
Let me start here, because the industry conversation has overcorrected.
Microservices have real costs:
- Distributed systems complexity: Network calls fail. Latency compounds. Transactions that were trivial in a monolith require coordination protocols.
- Operational overhead: Each service needs its own deployment pipeline, observability instrumentation, and operational runbook. This overhead scales with service count.
- Organisational requirements: Conway's Law is real. Microservices only work well when team boundaries match service boundaries. Many organisations aren't structured for it.
If you're a team of 10 shipping a product to find product-market fit, microservices will slow you down. The marginal engineering time spent on distributed system plumbing is time not spent on product learning.
Start with a modular monolith — clean internal boundaries, proper layering, well-defined domain modules. You'll be surprised how far it takes you.
The Signals That It's Time
So when does decomposition make sense? I use four signals:
1. Independent scaling requirements When different parts of your system have genuinely different scaling characteristics — a compute-intensive processing pipeline alongside a low-latency API — running them as a single process means scaling the whole thing to meet the highest demand. The cost adds up.
2. Different deployment cadences If one team needs to ship changes daily and another ships monthly, coupling them in a single deployable creates artificial release coordination. That coordination cost compounds.
3. Technology isolation requirements Some workloads genuinely benefit from different technology choices — a machine learning pipeline, a realtime event processor. If these can't coexist in a single runtime, separation is warranted.
4. Team scaling beyond communication threshold Amazon's "two-pizza team" heuristic exists for a reason. When a codebase is owned by more people than can maintain shared context, coordination costs grow super-linearly. Service boundaries become team boundaries.
How to Do It Without Catastrophe
The most successful decompositions I've seen share a few characteristics:
Extract at domain boundaries, not technical layers. Don't pull out "the database layer" — extract "the payment processing capability". Domain-oriented services are more stable than technically-oriented ones.
Strangle, don't rewrite. The strangler fig pattern — gradually routing traffic to new services while keeping the old system running — is almost always safer than a big-bang migration.
Instrument everything before you extract. You cannot safely extract a component you cannot observe. Distributed tracing and structured logging are prerequisites, not optional extras.
Treat the internal API as a contract from day one. Even while the components are still in the same codebase, define the interface as if it were external. This discipline pays off when you eventually separate them.
The Uncomfortable Truth
Many teams decompose into microservices not because the technical case is compelling, but because it feels like what sophisticated engineering organisations do. That's the wrong reason.
The right question is always: what problem am I solving, and is this the right tool for it? Architecture is a means to an end — faster delivery, better reliability, independent scaling. If decomposition serves those ends in your context, do it. If it doesn't, don't.
Working through an architecture decision about decomposition? I'm happy to think through it with you — get in touch.