Both costs, neither benefit
The most common way microservices fail is not picking the wrong boundaries. It is splitting the deployment without splitting the coupling.
What you get is a distributed monolith: services that must be released together, that call each other synchronously in long chains, and that often still read each other's tables. You now pay latency, partial failure and operational overhead on every request, and you still cannot deploy independently. Both costs, neither benefit.
The symptoms
Spot the symptoms, which are easy once you can name them. A release train, where six services version-bump and deploy together in a ceremony, means your API boundaries are decorative.
A change to one service that needs same-day changes in three others means you cut the domain along the wrong lines. Services sharing a database means there is no boundary at all, only a monolith with extra network cables.
Do the availability arithmetic on a synchronous chain four deep. Five services at 99.9 percent each gives you about 99.5 percent for the chain, and your slowest hop sets your latency floor.
Ask how teams get here, because the route is predictable. Usually by decomposing along technical layers, an auth service, a database service, an email service, instead of business capabilities like orders and payments and catalogue.
Technical layers all change together when a feature changes, so the coupling survives the split intact. The other route is splitting the code and deferring the data migration, then never finishing it, because the data migration is the hard 80 percent.
Run this test on any split somebody proposes. Can this service deploy on a random Tuesday without telling anyone, and can it stay up, possibly degraded, when its neighbours are down?
If either answer is no, you are not building microservices. You are adding network calls to a monolith.
Worked example
Segment wrote up the sharpest public version of this in 2018. They had split their integrations pipeline into a service per destination, over 140 of them sharing common libraries. A fix to a shared library meant rebuilding and redeploying more than 140 services, and the team spent its weeks managing queues and versions instead of shipping. They collapsed the fleet back into a single service, Centrifuge, and reported that the team went from barely keeping up to actually building features again. The services had never been independent; they shared code, shared fate, and shared a release process. Segment's engineers didn't frame the retreat as microservices failing, but as paying distribution costs for boundaries that were never real.