When Microservice Refactoring Turns Into a Distributed Monolith: Risks and Remedies

During a group chat about microservices, the author encountered the term "distributed monolith" and decided to share insights for readers who haven't seen the earlier article.

Many companies in China attempt a microservice transformation but end up with a system that looks like microservices on the surface while still behaving like a monolith—sometimes even worse.

Why a Distributed Monolith Is Bad

Consider whether your migration followed these steps:

Define business domains, split storage, and set service boundaries.

Refactor code to replace internal service calls with remote calls such as Dubbo or Feign.

These steps bring apparent benefits:

Separate codebases reduce merge conflicts.

Independent CI/CD pipelines allow each service to be built, deployed, and run separately.

Isolated databases prevent cross‑module data interference.

However, the transformation often fails to achieve the core goals of microservices. Questions arise:

Are the codebases truly iterated independently, or do many features still require coordinated synchronous interfaces?

Is each release truly autonomous, or must multiple services be deployed together?

If one service crashes, does it still bring down many functionalities?

Development efficiency may actually decline: a monolith that started in 3 minutes now requires launching several projects, each taking 30 minutes, making debugging and testing cumbersome.

Thus, the perceived gains are offset by higher operational complexity and reduced stability.

Root Causes of a Botched Refactor

Two main factors lead to the problems described:

Unreasonable domain splitting that creates excessive synchronous remote calls. Proper domain modeling and reducing sync calls—replacing them with asynchronous messaging and, where needed, data redundancy—lower coupling and mitigate distributed‑system failures.

Rudimentary implementation lacking distributed protection mechanisms. Teams often skip rate‑limiting, fallback, and circuit‑breaker strategies, leaving services vulnerable to cascading failures.

Effective protection requires disciplined design: reasonable domain boundaries, async communication, and robust resilience patterns. Without these, the added complexity of remote calls degrades system stability and increases the burden on developers.

Finally, reflect on your own microservice journey: does it exhibit the symptoms above, or are there different challenges? Share your experiences and thoughts in the comments.