Netflix moved from a very large number of fine-grained microservices toward fewer, better-bounded services. What signals indicate that service boundaries are wrong, and how would you execute a consolidation safely?

The signals that boundaries are wrong

• Lockstep deployment. Changing one feature requires coordinated releases of several services. This is the single clearest signal: the services have separate deployment pipelines but not separate reasons to change.
• Chatty synchronous call chains. A user request fans out through five or more services in sequence. Every hop adds latency and a failure mode, and the availability of the chain is the product of the members' availability — five services at 99.9% is 99.5%.
• Shared database or shared schema ownership. If two services write the same table, they are one service with extra steps and a distributed-transaction problem nobody has admitted to.
• A team that owns eleven services. Ownership diluted below the point where anyone knows the whole picture, with per-service overhead (pipeline, dashboards, on-call runbook, dependency upgrades) multiplied.
• Distributed transactions appearing. Sagas and compensations introduced because an operation that is logically atomic was split across boundaries. The compensation logic is the bill for the wrong boundary.

What the boundary should follow

Independent reason to change, independent scaling profile, independent failure isolation, and independent data ownership. A service that has none of these four is a module that has been given a network interface.

Executing the consolidation safely

1. Measure first. Call graphs from tracing, deploy correlation (which services release together), and the change-coupling history from version control. Merge on evidence, not on intuition.
2. Merge the code before merging the data. Bring the services into one deployable with the internal module boundaries preserved. Nothing about the data model changes yet — this step is reversible.
3. Collapse the call into an in-process call, removing serialisation and the network hop. Latency should fall measurably here; if it does not, the hop was not the problem.
4. Then unify the data, which is the irreversible step and belongs last.
5. Keep the module boundary in code. A merged service with enforced internal boundaries can be split again; one that becomes a mud ball cannot.

The trap

Consolidation is as capable of being cargo-culted as decomposition. The goal is boundaries that match the system's actual change and failure patterns, and the count of services is an output of that, not a target.