What is a "Distributed Monolith"?

A Distributed Monolith is an anti-pattern in which a system looks like a set of microservices on the outside, but in practice behaves like a single monolith.

#The essence

The services are formally separated, but have rigid dependencies:

• they require simultaneous deployment,
• they are tightly coupled through API calls,
• they cannot work independently.

In essence: the system gained the complexity of being distributed, networking, DevOps, orchestration, but did not gain the benefits of microservices: autonomy and flexibility.

#Signs of a "distributed monolith"

1. Services cannot be deployed separately: changing one requires recompiling the others.
2. Too many synchronous calls: every request "drags along" a chain of 5-10 services.
3. Shared libraries or a database: a schema change breaks everything.
4. No independent versioning: everything is released as "one big commit".
5. Frequent cascading failures: one service going down brings down the whole system.

#Why this is bad

• Loss of independence and scalability.
• Releases and testing become more complex than with a monolith.
• The system is overloaded with network calls and DevOps complexity without any payoff.

#How to avoid it

• Split services by bounded context.
• Use asynchronous communication and clear API contracts.
• Isolate data and releases.
• Introduce contract tests between services.

Summary:

A Distributed Monolith is "a monolith cut apart over the network". It is complex, fragile, and defeats the purpose of a microservice architecture. The main sign is that dependency between services is stronger than their autonomy.