Fewer services, clearer boundaries
Most microservice pain is boundary pain. A simple test for whether you have cut in the right place.
Teams usually discover their service boundaries are wrong about six months in, when every feature starts requiring a coordinated release across three services.
That coordination requirement is the test. If a typical change touches one service, the boundary is holding. If it routinely touches several, you have distributed a single component across a network and bought yourself latency, partial failure and deployment coupling in exchange for nothing.
The fix is usually to merge, not to add more services or more orchestration. That feels like going backwards. It is not: a well-drawn boundary is the whole point, and there is no rule that says you must end up with more services than you started with.
Start with a monolith when the domain is still moving. Extract a service when you have a specific reason — an independent scaling profile, a different team owning it, a different compliance boundary. Extraction without a reason is just cost.