Microservice Independence

There’s no magic number for “how many microservices should this monolith become.” Before you even chase a count, check whether a candidate split would actually behave like a microservice.

A few high-level expectations show up every time this question does.

Loosely coupled

Updating one service should not force you to update another.

If you have two services and shipping a change in A means you also have to ship B in lockstep, they aren’t loosely coupled. They’re still one release unit with a network cable between them.

Independent code, test, and deploy

Engineers should be able to code independently, test independently, and deploy independently.

If you have four services, there should not be a dependency that forces people to coordinate every release just to land work on one of them. Each service should have its own release cycle, test cycle, and ownership cycle.

Less communication overhead

If two services constantly need each other’s help for every small operation, they were probably never meant to be two services.

Talking a lot over the network is a smell. Merge them. Frequent chatter means they aren’t loosely coupled in practice — and that kills the next property too.

Scale independently

One big reason you split at all: if one piece of the system is getting hammered, you scale that piece.

If A and B chat on every request, you can’t scale them independently in a clean way. The hot path still drags the other service along. So reduce that chatter — or don’t split them in the first place.

Those four checks together are the independence test. Good split vs chatty split:

Good split

Good splitBad split

Own deploy · own scale · change A without shipping B

Independence is a check on a proposed boundary — not a mandate to maximize service count.

Good split                         Bad split (chatty pair)

[Service A]     [Service B]        [Service A] ←──lots──→ [Service B]
     │               │                    │                     │
  own deploy      own deploy         shared pain           shared pain
  own scale       own scale          can't scale alone     can't scale alone

When not to use this framing

Don’t use “independence” as an excuse to carve every class into a service. Independence is a check on a proposed boundary — not a mandate to maximize service count.

If the team is small and the domain is still changing weekly, optimizing for independent deploy of ten tiny services often costs more than it saves.

Production pitfall

“Independent deploy” on paper, shared library / shared schema / shared release train in practice. Teams say the services are separate, then every PR waits on a common package bump. Treat the release unit as the real boundary. If two repos always ship together, they’re one service with extra ceremony.