The real question is organisational, not technical
A service boundary that doesn't match a team boundary creates coordination overhead that exceeds whatever technical benefit the split was meant to deliver — two teams now have to coordinate deployments and API contracts across a boundary that exists on a diagram but not in how the organisation actually works.
Before debating service granularity, debate team structure: can this capability genuinely be owned, deployed and operated independently by one team. If not, splitting it into a separate service mostly adds network latency and operational surface without the independence that was the entire point.
The default cost of distribution
Every service boundary adds network calls where there used to be function calls, each with its own failure mode, retry logic and observability requirement. This cost is justified when it buys genuine independent deployability and scaling. It's pure overhead when it doesn't, because the teams on either side still have to coordinate releases anyway.
A well-structured modular monolith, with clean internal boundaries and genuine module ownership, often delivers most of the organisational benefit microservices are sought for, at a fraction of the operational cost — and it's a far easier starting point to split later, once a real independence need is proven.
A better sequencing
Start with clear internal module boundaries and genuine team ownership within a single deployable unit. Extract a service only when a specific, demonstrated need exists — independent scaling characteristics, a genuinely separate release cadence, or a regulatory isolation requirement — not by default.
This sequencing captures most of the organisational clarity benefit immediately, and defers the real distributed-systems cost until it's actually earned by a concrete requirement, not a stylistic preference.
A microservice that no team can own independently is not a microservice. It is a monolith with worse latency.MNB Software Practice
Key actions
- Match service boundaries to real team ownership boundaries
- Start with modular boundaries inside one deployable unit
- Extract a service only for a demonstrated, specific need
- Weigh network/observability overhead honestly against the benefit sought