Microservices can be a useful way to separate ownership and deployment. They also turn local decisions into distributed-systems decisions: network failures, retries, versioned contracts, tracing, and data consistency.
Start with boundaries, not service count
An early product often benefits from one deployable application with clear modules. The team can keep transactions local, debug with ordinary tools, and change a workflow without coordinating several release pipelines.
Split a module when there is a concrete reason: a different scaling profile, an independent release cadence, a strong ownership boundary, or an integration that needs isolation. A diagram with many boxes is not evidence that the system needs many services.
What changes after a split
A service boundary creates an API contract and an operational responsibility. The team needs a way to trace a request across processes, handle partial failure, deploy compatible versions, and decide which system owns each piece of data.
These costs can be worthwhile. They should be named before the split and revisited after the first production incidents. If a boundary makes the system harder to change without improving ownership or reliability, it may be the wrong boundary.
A useful first step
Before extracting a service, write down the workflow, its data owner, failure modes, deployment needs, and the reason the boundary exists. If the answers are unclear, improve the module boundary inside the existing application first.