Microservices vs. Monolith: What Actually Justifies the Split

Ask what's actually being coupled: is it the code, the deployment, or the failure domain? Messy code inside a single service is a refactoring problem, and a service split doesn't fix it, it just moves the mess across a network boundary where it's harder to trace.

A deployment coupling problem looks different: one team's change can't ship without another team's sign off, because their code lives in the same build and release pipeline. That's the pain a service boundary genuinely solves, by giving each team its own deploy pipeline for the piece it owns.

If one team owns the whole codebase, or if two or three teams rarely touch the same modules, a monolith with clean internal boundaries usually outperforms a service split on every axis that matters: fewer moving parts to operate, simpler debugging, and no network calls standing in for what used to be a function call.

A monolith also keeps transactions simple. A single database transaction that used to update three related tables becomes a coordination problem across three services once you split them, and that coordination problem is real engineering cost you're taking on, not a side effect you can ignore.

The strongest signal is a recurring, specific pain: a component with wildly different scaling needs than the rest of the system, or a component whose failures keep taking down unrelated features because they share a process and a deploy. If your recommendation engine needs ten times the compute of everything else, or a flaky third-party integration keeps crashing the whole app instead of just itself, that's a concrete case for isolating it.

A vague sense that "the codebase is getting big" isn't that signal. Size alone is a refactoring problem you can usually solve with better internal module boundaries, without touching your deployment topology at all.

Splitting a service out is justified by signals like these:

• A component has wildly different scaling needs than the rest of the system.
• A component's failures repeatedly take down unrelated parts of the system with them.
• Several teams cannot deploy independently because they are coupled through the same deployment.
• The pain is recurring and specific, not a general feeling that the codebase is messy.

The cost that catches teams off guard isn't writing the second service, it's everything that comes with running two services instead of one: distributed tracing to follow a request across a network hop, retry and timeout logic for calls that used to be reliable function calls, and a data consistency story for anything that used to be one database transaction.

Teams that split early usually end up with a distributed monolith: two or more services that still deploy together because they're too tightly coupled to change independently, but now pay the network and operational tax of being separate processes. That's the worst of both models at once, and it's a common enough outcome to plan around rather than assume you'll avoid it.

Before extracting a service, enforce the same boundary inside the monolith first: a module with a defined interface that the rest of the codebase can only call through, not one that other modules reach into directly for a shortcut. If a team can maintain that discipline inside a single deployable, splitting it out later is mostly an infrastructure change, not a redesign.

If a team can't maintain that discipline inside a monolith, splitting the module into its own service usually doesn't fix the underlying problem either, it just makes the boundary violation a network call and a production incident instead of a code review comment. Fix the discipline first; the physical split is the easy part once the boundary is real.