All insights
ArchitectureEngineering · 5 min read

When microservices stop being microservices

Most "microservices" architectures end up as distributed monoliths, all the deployment overhead, none of the independence. Spot it early.

Microservices promise independent deployment, fault isolation, and team autonomy. In practice, most "microservices" architectures deliver none of these: services that have to ship together, fail together, and can only be understood together.

The signs you’re a distributed monolith

  • Any code change touches three services.
  • Services share a database schema or deployment pipeline.
  • An outage in one service brings down half the others.
  • Nobody can describe what a single service is responsible for in one sentence.

What to do

Either go back to a well-organized monolith, which is fine, or do the work to make the services actually independent. The worst option is the current state: all the cost, none of the benefit, but with extra DNS to debug.

Microservices that ship together aren’t micro and aren’t services.

Have something that should run itself?

Tell us what runs by hand today. We reply within one business day with a first idea.