Microservices vs Monolith — When to Split

Microservices give you independent deployability and independent scalability — but at the cost of in-process calls, shared-database transactions, and simple single-service debugging. The decision should not be about the pattern's popularity but about whether you have a concrete problem that microservices solve better than a well-structured monolith.

When the split makes sense:

• Deploy contention is the clearest signal — when teams routinely block each other's releases and merge-to-production takes three days due to coordination overhead, that organizational friction is exactly what microservices fix
• Scaling skew is the second signal — when one module needs 10× the compute of everything else, you're paying to scale the whole monolith to support one hot component
• Domain boundaries should be stable for at least six months before extracting — use Domain-Driven Design to identify bounded contexts first

The distributed monolith trap:

• Splitting code without splitting data or decoupling call paths gives you network latency plus tight coupling — no real independence gained
• If Service A can't deploy without coordinating with Service B, you haven't actually split; you've just added network hops to your monolith
• Services that call each other synchronously for every operation recreate the coordination problem in a more expensive form

How to migrate safely:

• Always use the Strangler Fig pattern — route traffic at the gateway incrementally to new services while the monolith handles everything else
• Start with low-risk, well-bounded domains like notifications or user profiles, not payments or checkout
• Maintain a rollback path at every step — gateway routing is a one-line revert, and the monolith's code stays intact for at least one release cycle

I recommend the monolith-first default: only split when you can name the concrete problem — deploy contention, scaling skew, or team ownership — that microservices solve better than a modular monolith.