The microservices decision is usually made for the wrong reason, which is that the codebase has become unpleasant to work in. Splitting it into services does make each piece smaller. It also converts every function call that crossed a module boundary into a network call that can fail, time out, or arrive twice, and it converts every schema change into a coordination problem between teams. You have not removed the complexity; you have moved it somewhere harder to debug.
The honest test is organisational, not technical. Microservices solve a deployment-coordination problem: they let independent teams ship independently without queueing behind each other's releases. If you have four teams that keep blocking each other at release time, that is a real problem and service boundaries are a real solution. If you have one team of eight people, you do not have that problem, and distributing the system buys you distributed-systems failure modes in exchange for nothing.
What most teams actually want is a modular monolith: one deployable unit, but with genuine internal boundaries - modules that own their data, expose defined interfaces to each other, and cannot reach into each other's tables. That gives you the comprehensibility and the option to split later, because a module with a clean interface is a service waiting to be extracted. A tangled monolith cannot be split at all, which is why teams in that situation propose a rewrite instead.
If you do split, the boundaries should follow business capability and team ownership, not technical layers. A service that owns ordering, end to end, including its data, is a service. An authentication service, a database service and a validation service are layers wearing service costumes - every business change touches all three, and you have gained the network without gaining independence.
Be honest about the operational bill before committing. Microservices require service discovery, distributed tracing correlated by request, centralised logging, per-service CI/CD, contract testing between services, and a way to run a meaningful subset locally. That is a platform, and building it takes a team. Organisations that adopt microservices without funding that platform end up with the coordination cost of distribution and none of the deployment independence that was the point.
The pattern we would recommend for most companies: start as a modular monolith with disciplined boundaries, and extract a service only when you can name the specific pain that extraction removes - this team is blocked by that team's release cadence, or this component genuinely needs to scale independently. Extraction driven by a named problem tends to work. Extraction driven by a diagram tends to produce a distributed version of the same tangle.
