A platform adopts microservices and now needs service discovery, distributed tracing, multiple pipelines, a message broker and complex local development. Which of these costs are inherent and which indicate a boundary problem?

Inherent costs

These come with distribution and cannot be engineered away:

• Service discovery and load balancing, because endpoints are dynamic.
• Distributed tracing, because a request spans processes and no stack trace covers it.
• Network failure as a normal condition — timeouts, retries, circuit breakers, partial failure.
• Eventual consistency wherever a transaction previously spanned components.
• Multiple deployment pipelines, which is the point rather than a cost.
• Operational surface proportional to service count.

If these are unacceptable, the answer is fewer services, not better tooling.

Costs that indicate a boundary problem

• Complex local development requiring many services running. If a change cannot be developed and tested against one service with stubs, the boundaries are wrong — the service is not independently comprehensible.
• A message broker needed for what should be a local call. Asynchrony introduced to decouple components that should not have been separated.
• Coordinated releases. If several services must ship together, nothing was decoupled — this is a distributed monolith, with the operational cost of distribution and the change cost of a monolith.
• A single business change touching four services, meaning one piece of knowledge has four implementations.
• A shared database, which makes the schema an unversioned interface between teams.
• Cascading failures across services that should be independent, indicating hard dependencies where soft ones belong.

The diagnostic question

Can one team change, test, deploy and operate its service without coordinating with another? If not, the distribution is providing costs without benefits, and consolidating those services is a genuine architectural improvement rather than a retreat.

The reframing worth stating

Microservices solve an organisational scaling problem — many teams shipping independently — and charge a distributed-systems problem for it. A platform with three teams and forty services has paid the charge and not received the benefit.

Reducing distribution is a legitimate scalability improvement when the constraint is change velocity rather than runtime scale, and framing it as a retreat is what prevents teams from making an obviously correct correction.