Distributed Monolith
A distributed monolith consists of separately deployable units whose changes or disturbances are nevertheless closely related. Shared data and coordinated releases can devalue process boundaries.
- Common statusSeveral services write the same data.
- Coordinated releasesChanges force joint extradition.
- Writing sovereigntyCorrection: a business owner.
Context
Why this is important
Separate services that need to be published together bear the costs of distributed systems without their autonomy. Network calls and coordination are added, the benefit is missing. The specific coupling example shows Shared Database.
This Building Block diagnosed distributed coupling. Shared Database shows a concrete interconnection path; trade-off analysis compares possible structural changes.
At a glance · Distributed, but shared
Module boundary and distributed coupling
Variant: Order and shipping services share a table and must be published together. A modular monolith structure remains the starting variant of the shop.
This is how you read the picture
- Common status Line “Data Responsibility”, right column: “Multiple services write the same status”.
- Coordinated releases Line “Change”: “Change coordinates multiple releases” in the distributed variant.
- Writing sovereignty Line ‘Direction of correction’: ‘Assigning jurisdiction and decoupling services’.
| Criterion | Modular monolith baseline | Distributed variant with common table |
|---|---|---|
| Data Responsibility | Module has status and interface | Multiple services write the same status |
| Changes | Versioning the contract together in the shop | Change coordinates several releases |
| Collapse | call within an application | Network call plus shared storage |
| Correction direction | Strengthening module contracts | Assign writing sovereignty and decouple services |
Benefits & limitations
Helps if:
- Regularly coordinated releases for individual business changes show close coupling between services.
- Synchronous chains and shared data responsibility combine errors and delays across process boundaries.
Boundaries
- A joint release can make sense for the business; assess frequency across several changes rather than one isolated case.
- Asynchronous messaging decouples timing; data ownership and shared rules, such as those in Shared Database, remain sources of coupling.
- The modular shop needs no separation while its module boundaries hold; Architecture erosion shows when they weaken.
In practice
- Collect change and operational data. Record release coordination, shared data access and failure chains across several operations. Map each observation to a business capability. This exposes recurring coupling patterns across changes.
- Locate responsibility and the bottleneck. Determine which component should control a business decision and its data. Trace synchronous call chains and the consequences of their failures. This makes potential boundary shifts concrete.
- Reassess the change path. Choose a structural measure such as contract evolution, consolidation or independent data ownership, then observe the next comparable change. Compare the number of coordinated units and the scope of failure. This shows whether independence has actually increased.
Read the detailed explanation
A distributed monolith consists of multiple deployable units whose changes or failures remain tightly linked. Shared tables, long synchronous call chains and regularly coordinated releases can undermine process boundaries. Diagnosis uses recurring change and failure paths and complements concepts such as Shared Database and Coupling.
Correction starts with business responsibility, data ownership and compatible contracts. Tightly coupled parts can be consolidated or their dependencies deliberately reduced. Adding messaging alone does not create independence while shared decisions and write paths remain. What matters is whether teams can handle changes and failures within useful boundaries. Distribution remains worthwhile when it supports independent responsibility. Otherwise, consolidation or a more stable contract can reduce network and coordination overhead.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
What applies in the distributed variant for the failure effect?
View the solution with justification
It includes a network call plus shared memory, while in the modular monolith, the call remains within an application.
ApplyingTransferred to a new situation
Order and shipping service share a table and are always rolled out together. What first step are you taking?
View the solution with justification
Determine which service will write the status, and let the other use it through a compatible contract. After that, both can be published independently.
EvaluateWeighing an alternative
Alternatively, the shop could return to the modular monolith. What is the advantage and what price?
View the solution with justification
The advantage is a call within an application with a common release. The price is that the services can no longer be provided individually.
Explore further
These building blocks continue the thoughts of this page.
References
- Martin Fowler – Microservice Premium (opens in new tab)Explains the additional effort of distributed services and necessary module boundaries.
- How to break a Monolith into Microservices (opens in new tab)Shows decoupling and gradual extraction along meaningful boundaries.
- Sam Newman – Principles of Microservices (opens in new tab)Organizes independent provision, isolation and service autonomy as design principles.