How to Decide Where Your Next Service Boundary Actually Belongs

A module whose load pattern is genuinely different from the rest of the application, say a video processing job that runs long and uses heavy compute against a codebase that otherwise handles quick web requests, benefits from its own boundary so it can be scaled and resourced independently. A module that scales roughly in step with everything else gains little from separation and pays the cost of a network hop for no real benefit.

This is the strongest, most concrete criterion of the four, because it's measurable rather than a matter of team preference.

A module that needs to ship several times a day, independent of the rest of the system's release cycle, is a candidate for its own service specifically so its deploys don't have to wait on or risk everything else. A module that always ships alongside the rest of the application gains nothing from a separate deploy pipeline and just adds coordination overhead between services that are, in practice, always released together anyway.

DORA's own research treats deployment frequency as one of the clearest signals of delivery performance, and it's worth asking, module by module, whether a shared deploy cadence is actually holding a specific piece of the system back¹.

A module owned cleanly by one team, with a narrow, stable interface to the rest of the system, is a good boundary candidate: splitting it lets that team move without coordinating every change with everyone else. A module whose logic is tangled across concerns owned by several teams is the opposite case; splitting it before untangling the ownership just moves the coordination problem across a network boundary instead of solving it.

If you can't name the one team that would own the new service cleanly, that's a sign the split is premature, not that it needs a bigger team to support it.

Every new service adds its own deploy pipeline, its own monitoring, its own on-call surface, and its own failure modes to reason about. A team without the operational maturity to run what they already have is not helped by adding another moving part, no matter how clean the logical boundary looks on a whiteboard.

Be honest about this one specifically. It's the criterion most often skipped because it's less interesting to discuss than the architecture itself, and it's also the one whose absence causes the most pain months after the split.

A module that fails most of these four criteria is better served by a clean internal boundary, a well-defined module or package inside the existing codebase, than by a network boundary. An internal boundary gets most of the benefit (isolated ownership, a clear interface, the option to extract it later) without the operational cost of a separate service. Extraction is much easier to do later, once a criterion genuinely starts failing, than reversing a premature split is to undo.

The most useful version of this decision isn't a single architecture meeting early in a project's life; it's a short, repeatable exercise applied whenever a module starts feeling like it might deserve its own boundary. Keep the four criteria as a standing checklist rather than relitigating the whole microservices-versus-monolith question from scratch every time someone proposes a split.

A module that fails all four criteria today might pass two of them in a year as the system and team grow. Revisiting the same module against the same criteria periodically is a far steadier way to make this decision than waiting for a single big rearchitecture conversation to settle it once and for all.

Ask these four questions about any module before splitting it out:

• Does it scale differently from the rest of the system, with a load pattern that would benefit from independent resourcing?
• Does it have a genuinely different deploy cadence, needing to ship far more often than the rest of the application?
• Would splitting it reduce the number of people who must coordinate, given a single owning team and a narrow, stable interface?
• Can your team actually operate another service, including its pipeline, monitoring, on-call surface, and failure modes?