Why Your “Distributed Monolith” Undermines Microservice Success

Last night before sleeping I casually collected some group chat logs and discovered the term “distributed monolith”. The discussion revealed that some companies attempt microservice refactoring but end up with a system that looks like microservices in form yet remains monolithic in essence, or even worse.

This phenomenon is common in China. In this article we explore the “distributed monolith” and ask whether your company has made the same mistake.

Why a Distributed Monolith Is Problematic

Consider the typical steps when moving from a monolith to microservices:

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

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

These changes bring apparent benefits:

Separate codebases reduce merge conflicts.

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

Isolated databases prevent modules from affecting each other.

However, simply splitting does not guarantee the core goals of microservices. Ask yourself:

Are the codebases truly iterated independently, or do you still need to coordinate many synchronous interfaces?

Is each CI/CD release truly independent, or must multiple services be released together?

If a single service fails, does it still cause many features to break?

Even though startup time dropped from three minutes to thirty seconds, developers now have to launch several projects simultaneously, which may not improve overall development experience.

In practice, the “distributed monolith” often yields minimal benefits while introducing new drawbacks such as higher failure frequency and poorer stability compared to the original monolith.

The increased instability stems from turning internal calls into remote calls, adding network I/O and raising the fault rate of each interaction. As the number of synchronous remote calls grows, the overall system failure probability rises, especially when operational and development practices do not keep pace.

Root Causes of a Misguided Refactor

Two main factors lead to the problems described above:

Unreasonable domain splitting that creates excessive synchronous remote calls. Proper domain modeling and reducing synchronous calls—favoring asynchronous messaging and selective data redundancy—can lower coupling and mitigate distributed‑system failures.

Rudimentary implementation lacking protective mechanisms for distributed environments, such as rate limiting, degradation, and circuit‑breaker strategies on both provider and consumer sides. Without these safeguards, added complexity degrades system stability.

Addressing the first issue through thoughtful domain design enables developers to implement the necessary protection mechanisms more effectively, ultimately improving both development quality and system reliability.

Reflect on your own microservice migration: does it suffer from the same pitfalls, or are there different challenges? Share your thoughts in the comments.