Deciding Where to Draw Service Boundaries, and Where Not To

Every service you split off adds a network call where there was a function call, a separate deployment pipeline, its own on-call burden, and a new way for a partial failure to happen: the service being up but slow, or up but returning stale data. None of that is free, and all of it is easy to underestimate when the split looks clean on a whiteboard.

That cost isn't a reason to avoid splitting anything, it's a reason to make sure each specific split is paying for itself, rather than assuming services are simply the more modern default.

A boundary earns its cost when the two sides genuinely need to scale, deploy, or fail independently, a background job processor that needs to scale wildly during peak load while your main API stays flat, or a component with a fundamentally different reliability requirement than the rest of the system.

A boundary drawn along team lines, so each team can own its own service, is a legitimate reason too, but only once the team is large enough that shared ownership of a monolith is itself the bottleneck, not before.

Splitting two pieces of logic that always deploy together, always scale together, and are maintained by the same one or two engineers usually adds operational cost without buying any of the independence that's supposed to justify it. You get the network call and the separate deployment pipeline, without the scaling or ownership benefit that would make either worth it.

This is the most common overcorrection: teams that read about the benefits of services and split along technical layers, like a separate "validation service" or "formatting service," instead of along real independence boundaries.

How your services are split affects your deploy frequency: a team releasing on demand can keep changes small and contained to one service at a time, while a team stuck at monthly releases, often because too many services must move in lockstep, ends up bundling changes across boundaries that were supposed to be independent, which defeats much of the point of splitting them in the first place¹.

If your services can't deploy independently of each other in practice, that's a sign the boundary was drawn in the wrong place, not just a coordination problem to work around. Two services that must always ship in the same pull request or the same release window aren't really two services operationally, whatever the deployment diagrams say.

Before extracting a service, enforce the boundary inside the monolith first: a clean internal interface, no direct database access across the boundary, no shared internal state. If that internal boundary holds up cleanly for a few months, extracting it into an actual service is mostly mechanical.

If the internal boundary keeps getting violated, with shortcuts and direct reaches across it under deadline pressure, that's useful information too: it usually means the boundary wasn't a natural one, and splitting it into a separate service would have just made those violations more expensive to work around.

This approach also removes most of the risk of getting it wrong. Reverting an internal interface that didn't work out is a code change; reverting an already-extracted service, with its own deployment pipeline and its own on-call rotation, is a much bigger undertaking that teams tend to avoid even after they've realized the split wasn't worth it.

Follow this sequence before extracting a service:

1. Define a clean internal interface for the boundary inside the monolith.
2. Block direct database access across the boundary so each side owns its own data.
3. Remove any shared internal state between the two sides.
4. Watch whether the boundary holds for a few months, and treat repeated shortcuts as a sign the split may not pay for itself.
5. Extract the service only when the boundary holds and you can name a concrete reason it needs to scale, deploy, or fail independently.