One service or many: when to split
Why a monolith isn't a dirty word
One system is easier to deploy, debug and change across domains. Most projects split early got the full cost of splitting — network, versions, distributed monitoring, consistency — before they got any benefit from it.
Signs it's time
A release blocked because teams wait on each other; a component with entirely different resource needs; a part that requires a separate availability level or regulation; a very different rate of change between areas.
The sign that isn't enough: “because that's how it's built today.”
How to split correctly
By a business boundary and not a technical layer. Each service holds its own data and doesn't call another's database. Communication through an explicit contract, and events instead of synchronous calls where possible.
Before splitting, check that the boundaries work inside the monolith itself: well-separated modules are a cheap dress rehearsal.
Going deeper
Splitting requires infrastructure: distributed tracing, monitoring per service, config management, and a shared standard for errors and retries. If that infrastructure doesn't exist, the split won't solve a pace problem but will replace it with an operations problem.