A Microservice Should Reduce Coordination, Not Increase It

Here is a microservice smell I trust: you want to ship one small feature, but first you need meetings with ten teams.

I have seen worse versions where a change touched 20, 30, or 50 services. At that point, calling the architecture independent does not make it independent. You have a monolith with network calls and a larger cloud bill.

Five engineers and five services

A team of five engineers owning five microservices is not automatically modern. Often it means every engineer is carrying one service in their head while the team collectively carries five deployments, alert sets, dependency graphs, and incident histories.

I would ask a simpler question: can this team change its business area without asking half the company for help?

If the answer is no, making the services smaller will probably make the coordination problem worse.

Split around business boundaries

A large codebase is not a reason to split a service. An old codebase is not a reason either.

“Nobody understands this, so let us rewrite it as microservices” is how many organizations create a second system that nobody understands.

A stronger boundary usually follows a business capability:

• orders
• payments
• billing
• delivery
• identity

The code inside one boundary may remain large. Fine. A large service with clear ownership can be healthier than six small services that must change together.

When the split follows technical layers or arbitrary chunks of code, a business change cuts across all of them. This is the distributed monolith people complain about, although it probably looked very clean on the first diagram.

Microservices become legacy quickly

The first service I wrote after joining Delivery Hero in 2019 was scheduled for deprecation in 2026. Seven years can be enough for a once-modern service to become legacy.

That is not necessarily a failure. Systems age. Still, every service you create today becomes somebody’s migration project later.

Before creating one, ask:

1. Can this capability change independently?
2. Can one team own its operation and decisions?
3. Does it need an independent scaling or reliability profile?
4. Are its data and business rules clearly bounded?
5. Is the coordination cost lower after the split?

If several answers are no, keep the code together. A modular monolith is not an embarrassing intermediate step.

Architecture is an organizational design

Every network call can become a conversation, an approval, or an incident handoff. This is why I judge a microservice design partly by the calendar: how many people need to find time before one team can ship?

If the answer keeps growing, the architecture is telling you something.

For help reviewing boundaries and trade-offs, see system design coaching and technical strategy coaching.