Distributed Monolith Anti-Pattern

A distributed monolith is a system that looks like a microservices architecture from the outside — multiple deployable services, network communication, possibly a service registry and an API gateway — but behaves like a monolith on every axis that matters operationally: services cannot be deployed independently of each other, services share data through the same database tables, an outage in any one service brings down the whole system, and a change in any one service requires regression-testing the whole system before release. The pattern is the textbook negative outcome of the microservices migration era (~2014–2020). Sam Newman’s Building Microservices (2021, 2nd ed., chapters 1 and 3) describes it precisely: “all the costs of a distributed system, none of the benefits.” Mathias Verraes coined the related term Distributed Big Ball of Mud in 2014, applying the Big Ball of Mud Anti-Pattern vocabulary to multi-service contexts. The diagnosis is structurally important because the surface signs of a microservices architecture (a service registry, Kubernetes namespaces, separate Git repositories per service) do not at all guarantee that the underlying coupling has been broken; coupling can persist invisibly through shared databases, shared deployment cadences, shared on-call escalations, and tight synchronous request-response chains. Many organizations that completed a “microservices migration” between 2015 and 2020 ended up with this anti-pattern as their result, paid the operational cost of distributed systems, but did not gain the deployment-independence benefit that justified the cost.

The clarifying question for any architecture audit is not “do we have multiple services?” but “can a single service be modified, tested, and deployed without the others knowing or caring?” If the answer is no — if changing service A requires coordinated changes in services B, C, D and a synchronized deploy — then services A, B, C, D are one logical deployable unit that has been physically split for no operational benefit. This is the distributed monolith. The system is one logical monolith implemented across multiple processes, communicating over the network rather than over function calls, with all the latency, partial-failure, serialization, and operational complexity that distribution adds, but with none of the autonomy that distribution exists to provide. This note dissects the pattern: its definition, the canonical diagnostic signs, why it happens (Conway’s Law, shared data, missing bounded contexts), the worst-of-both-worlds problem framing, real-world incidents, the recognition diagnostics, the remediation strategies (including the controversial “re-consolidate to monolith” answer), and a worked example walking through an unwinding via the Strangler Fig Pattern applied internally to an over-decomposed system.

1. Definition — Looks Distributed, Behaves Monolithic

A monolith is a single deployable unit. All code is in one process; all changes ship together; one bug can take down the whole thing; one team’s deploy schedule constrains all other teams. A microservices architecture is the deliberate inversion: multiple small deployable units, each owning its own data, each independently deployable, each with its own failure domain. The microservices promise is that team A can ship its service on Tuesday without team B even being aware. The cost of that promise is real: distributed systems are dramatically more complex than in-process systems — partial failures, network latency, distributed tracing, eventual consistency, schema versioning, service discovery, all become first-class concerns where in a monolith they did not exist.

A distributed monolith is the architecture that pays the cost of microservices but does not deliver on the promise. The system looks distributed: there are 30 separate Git repositories, 30 separate Kubernetes deployments, 30 separate Datadog dashboards. But examine any of the operational axes that distinguish microservices from monoliths and the picture collapses:

• Independent deployment. Can service A ship on Tuesday without coordinating with services B and C? In a distributed monolith, no. Releases are coordinated; changes ripple through the call graph; an “integration testing” phase must run before any deploy because every service’s behavior depends on every other service’s exact contract.
• Independent failure. Can service A be down for 10 minutes without affecting services B and C? In a distributed monolith, no. Services are linked by synchronous request-response chains; if A is down, B’s calls to A time out, B’s response to its callers fails, the failure cascades. The whole system is up or the whole system is down — the same failure mode as a monolith but with extra network hops in between.
• Independent data ownership. Does service A own its data exclusively, with B and C accessing only via A’s API? In a distributed monolith, no. Multiple services read and write the same database tables (cf. Shared Database Anti-Pattern). Schema changes require coordinating with every service that touches the table.
• Independent scaling. Can service A be scaled out 10× without scaling B and C? In principle, yes (each runs separately); in practice, A’s behavior is so intertwined with B’s that scaling A without B causes B to bottleneck, so scaling decisions are still made for the whole system.
• Independent technology choices. Can service A be written in Go while B is in Python? In principle, yes; in practice, the cross-service contracts are so tight that the team cannot afford the friction of multiple languages and standardizes on one. (This is not strictly a sign of distributed monolith; many healthy microservices estates standardize on a single tech stack for legitimate reasons. But in a distributed monolith, the standardization is forced rather than chosen.)

When all of these axes show the monolithic pattern, the system is a distributed monolith. The architecture diagram shows distribution; the runtime behavior shows a monolith with extra latency and extra failure modes. Newman frames this trenchantly in Building Microservices: “Splitting a monolith into a distributed monolith makes everything worse — you have not solved the original problems and you have added new ones.” The new problems include all the Eight Fallacies of Distributed Computing (network is reliable, latency is zero, bandwidth is infinite, etc., all of which are false but which monoliths do not need to confront). The original problems — slow deployment, brittle changes, inability to scale teams independently — remain because the underlying coupling was never broken.

The deeper observation: microservices is a property of the runtime behavior, not the deployment topology. A system with one deployable unit that has clean internal modules with strict isolation can be more “microservice-like” in the relevant operational sense than a system with 50 deployable units that all share a database and deploy together. This is the kernel of the Modular Monolith counter-pattern (Shopify’s 2019 description of their own architecture is the canonical industry reference): they deliberately stayed monolithic at the deployment level but enforced strict modularization within the codebase, getting many of the benefits of microservices without the operational cost of distribution. Some of the loudest microservices skeptics (Kelsey Hightower, DHH) explicitly cite the distributed monolith failure pattern as the reason monoliths are often the right call.

1.1 Visualizing the Topology

flowchart TB
    subgraph "Microservices (healthy)"
        A1[Service A] -->|"async event"| Bus1[(Event Bus)]
        Bus1 -->|"event"| B1[Service B]
        Bus1 -->|"event"| C1[Service C]
        A1 -.->|"versioned API"| B1
        DB1A[(DB A)] --- A1
        DB1B[(DB B)] --- B1
        DB1C[(DB C)] --- C1
    end
    subgraph "Distributed Monolith (anti-pattern)"
        A2[Service A] -->|"sync RPC"| B2[Service B]
        B2 -->|"sync RPC"| C2[Service C]
        C2 -->|"sync RPC"| D2[Service D]
        A2 ---|"direct DB access"| SharedDB[(Shared DB)]
        B2 ---|"direct DB access"| SharedDB
        C2 ---|"direct DB access"| SharedDB
        D2 ---|"direct DB access"| SharedDB
    end

What this diagram shows. The top topology — healthy microservices — has each service owning its own database, with cross-service communication via asynchronous events through a message bus and versioned synchronous APIs for read paths needing consistency. Each service can be deployed, scaled, and failed independently because no shared resources or runtime dependencies tie them together. The bottom topology — distributed monolith — has all services connecting directly to a single shared database (the implicit schema-level coupling) and communicating via synchronous RPC chains (the runtime coupling). Even though the diagram shows multiple separate services, they are functionally one logical unit: a change to the shared schema affects all four; a slowdown in service D backs up the chain through C, B, and A; the database is a single point of failure for everything. The visual contrast makes clear that the difference between the two is not “how many services” but “how the services are connected” — the same service count can be either healthy microservices or a distributed monolith depending on the connectivity pattern.

2. The Canonical Diagnostic Signs

The distributed monolith is identifiable by a recurring set of operational symptoms. Each individually might be tolerable in an immature system; together they are diagnostic.

Sign 1: One service cannot be deployed without redeploying its callers. A change to service A’s response schema (adding a field, renaming a field, changing an enum value) breaks services B, C, D that consume A’s responses. To ship A, you must ship B, C, D in lockstep; the deploy is a coordinated operation involving all four teams. In a healthy microservices architecture, A versions its API (cf. API Versioning) and B, C, D continue using the old version until they each independently decide to migrate; the deploys are not coupled. The diagnostic question: “What is the largest set of services that have been deployed together in the last month? If the answer is ‘most of them, every Friday,’ you have a distributed monolith.”

Sign 2: Services share a database. Multiple services have direct database connections to the same instance, and especially to the same tables, with both read and write access. The shared database is the most reliable indicator; once present, it is essentially impossible to be anything other than a distributed monolith because the database schema is the implicit shared contract that all services depend on. This sign is so important and so common it has its own dedicated note: Shared Database Anti-Pattern. The diagnostic question: “If I run SHOW PROCESSLIST on the database, do I see connections from more than one service identity? If yes, you have a distributed monolith (or are well on your way to one).”

Sign 3: Deploys take hours because of system-wide integration tests. Each deploy triggers an integration test suite that exercises end-to-end paths spanning multiple services. The suite takes 90 minutes to run; flakiness adds another 30 minutes of retries; deploys are scheduled for off-hours because they cannot be done during peak load. In a healthy microservices estate, each service has its own contract tests that verify its API independently of consumers; consumers verify their own integration with the API contracts they depend on; the cross-service test surface is minimal because contracts are explicit and stable. The diagnostic question: “What percentage of our test wall-clock time is spent on tests that span more than one service?”

Sign 4: An outage of any one service brings down everything. Service A goes down for 5 minutes for a routine deploy. During those 5 minutes, services B, C, D start failing because their synchronous calls to A time out. Customer-facing requests fail because the call graph eventually reaches A. The system is “up or down” as a whole, with no graceful degradation. In a healthy microservices estate, services are resilient to dependencies’ failures (cf. Circuit Breaker Pattern, Bulkhead Pattern, Graceful Degradation) and asynchronous communication via messaging means temporary outages of A do not cascade. The diagnostic question: “When service X is down, what fraction of customer requests fail? If the answer for any single service is >20%, that service is a single point of failure indicative of distributed-monolith coupling.”

Sign 5: “We have 47 services” but “we deploy them all together every Friday.” The two statements contradict each other in a healthy architecture; in a distributed monolith they coexist. The deploy cadence is a more honest measure of the architecture’s true topology than the service count. If the deploy cadence is “every Friday, all 47 services,” the system is one logical unit that ships weekly; the 47-service count is a lie the deployment topology is telling. The diagnostic question: “Looking at the last 30 days of deploys, how many services were deployed independently of the others?”

Sign 6: Cross-service joins in code or in-memory data assembly. Service A’s response is built by calling services B, C, D, joining their data, and returning the merged result. Every read of A’s resource fan-outs to four backend calls. The joins enforce a strong runtime coupling — A cannot respond without B, C, D — and a strong contract coupling — A’s response shape changes if any of B, C, D’s response shapes change. The N+1 fan-out pattern (one request to A explodes into many requests to B) is the worst case. Healthy microservices use API composition or Backend for Frontend Pattern for this kind of aggregation, designed deliberately and limited to specific aggregation services. In a distributed monolith, every service exhibits this pattern internally.

Sign 7: Schema migrations require coordinating with every team. A change to the database schema (rename a column, change a type, add a foreign key) can only happen during a maintenance window because every service that touches the schema must be aware of and agree to the change. Migrations that should be backwards-compatible expand-then-contract operations (cf. Database Migration Patterns) become global synchronization events because the services share schema knowledge.

Sign 8: Distributed transactions or 2PC across services. Services participate in a distributed transaction (XA, 2PC, or hand-rolled equivalents) to maintain consistency. The presence of distributed transactions across service boundaries is a near-certain sign of a distributed monolith — the transaction is the coupling, and the architecture is one logical commit unit physically split into multiple services. Healthy microservices use Saga Pattern for cross-service workflows precisely to avoid distributed transactions.

Sign 9: A change in service A requires PRs in services B, C, D simultaneously. Pull requests are coordinated across multiple repositories. A new feature is split across 4 PRs in 4 repos that must all merge in a specific order on a specific day. The release process involves a Google Doc tracking which PR has merged where. This is the human-process surface of the deployment coupling: humans are spending time on coordination that the architecture should be making unnecessary.

Sign 10: One on-call rotation handles incidents in any service. If any service alarms, the same on-call engineer is paged regardless of which service is affected. This may sometimes reflect organization size (small teams legitimately share rotations) but often reflects that incidents in any service require diagnosis spanning multiple services — because the failure modes are not isolated to any one service.

When 4 or more of these signs are present, the diagnosis is essentially confirmed. When 7 or more, the system is a textbook distributed monolith and the cost-benefit math of microservices is being inverted.

3. Why It Happens — Conway’s Law, Marketing, and Failed Decomposition

Distributed monoliths arise from specific organizational and technical failure modes. Understanding the causes is a prerequisite for avoiding the trap.

3.1 Microservices Adopted as Marketing

The most common cause is that “microservices” was adopted as a goal in itself — for resume reasons, conference-talk reasons, “we want to be like Netflix” reasons — without a clear analysis of why the team needed microservices and what problems they were solving. Newman’s Building Microservices (2nd ed., chapter 1) is explicit: microservices are a means to an end (independent deployability, technology heterogeneity, robustness, scaling, organizational autonomy), and the right starting question is “do we need any of these benefits enough to pay the operational cost?” Many 2015–2020 migrations skipped this question. The team committed to microservices as the architecture style; the structural decomposition was rushed; the bounded contexts (cf. Domain-Driven Design Strategic Patterns) were never properly identified; the result was a monolith with extra hops.

Fowler’s 2015 Microservice Prerequisites essay (https://martinfowler.com/bliki/MicroservicePrerequisites.html) lists the operational maturity required for microservices to deliver on their promise: rapid provisioning, basic monitoring, rapid application deployment, devops culture. Without these, microservices can be technically constructed but cannot operationally function as microservices — they will end up as a distributed monolith because the team lacks the deployment automation to deploy them independently. Fowler’s MonolithFirst (also 2015) explicitly recommends starting with a monolith and only extracting services when the bounded contexts are well-understood; the inverse — starting with microservices and figuring out the boundaries later — is the path that produces distributed monoliths.

3.2 Decomposition Without Bounded Contexts

The second cause is decomposing the monolith along the wrong seams. The right seam for a microservice boundary is a Bounded Context — a cohesive area of the domain with its own ubiquitous language, owned by one team, with explicit and minimal contracts to other contexts. The wrong seams include:

• Decomposing by technical layer — separate services for “the database access layer,” “the business logic layer,” “the API layer.” This produces services that all need to talk to each other for any single request; every customer interaction fans out across all layers. The coupling is total.
• Decomposing by entity — one service per database table (UserService, OrderService, ProductService, AddressService, etc.). This sounds reasonable but tends to produce services that are too small to encapsulate any meaningful business operation; cross-entity operations require N service hops, and the entities are not the right boundaries because business operations span them.
• Decomposing by team’s existing structure — split the monolith along whatever lines the current teams happen to be organized around. Conway’s Law (see §3.3) makes this somewhat inevitable, but the failure mode is when team boundaries do not correspond to natural domain boundaries — the resulting services are arbitrary slices of the domain that need to constantly coordinate.
• Decomposing by file — every Java package becomes a service; every Ruby module becomes a service. The result is dozens of micro-services that are essentially function calls separated by network hops.

The right decomposition begins with Event Storming or Context Mapping sessions that identify the domain’s bounded contexts; services are extracted along those seams. This work is hard, requires deep domain knowledge, and is usually skipped in distributed-monolith migrations because it would slow things down. The result is services along arbitrary seams that have not solved the underlying coupling.

3.3 Conway’s Law — The Architecture Reflects the Organization

Conway’s 1968 observation: organizations design systems that mirror their communication structures. If your organization has six teams, your architecture will have six communicating subsystems, regardless of what’s technically optimal. This is sometimes called Conway’s Law and sometimes the “Inverse Conway Maneuver” (consciously structuring teams to produce the desired architecture).

The distributed-monolith failure mode in Conway’s-Law terms: the team boundaries before the migration were tangled, with no team owning a coherent domain area. The migration created services along the existing team boundaries. Because the team boundaries were tangled, the resulting services are tangled — services owned by different teams must constantly coordinate because the work that touches them cannot be cleanly assigned to a single team. The architecture has inherited the organizational tangling.

The fix at the organizational level: re-team. Identify the bounded contexts; assign each to a team; let teams own their service end-to-end. This is operationally expensive (re-teaming has its own costs) but is often the only way to truly resolve the distributed monolith.

3.4 Shared Data Forced Shared Deployment

Often the migration kept the database as a single shared database for “performance reasons” or “schema-migration coordination reasons.” The shared database is then the implicit coupling that makes services unable to deploy independently. This is the Shared Database Anti-Pattern and is so common a cause of distributed monoliths that the two patterns are essentially partner symptoms. Eliminating the shared database is usually the single highest-leverage step in resolving a distributed monolith.

3.5 Synchronous-Only Communication

Services communicate exclusively via synchronous HTTP request-response calls. There is no message bus, no event log, no asynchronous communication primitive available. In this style, every cross-service interaction is a tight runtime coupling: service A waits for service B’s response before A can respond to its caller. The call graph chains together every customer request through multiple services, and any latency or failure in any single service propagates to all of them.

A healthy microservices estate uses asynchronous communication — events, message queues, durable logs (cf. Event-Driven Architecture, Distributed Log System Design, Publish Subscribe System Design) — for cross-service workflows that don’t need synchronous responses. Order-placement: synchronous to commit the order locally, asynchronous to notify shipping and inventory. The asynchronous decoupling is what allows services to deploy and scale and fail independently. Without it, services are essentially function calls over the network — synchronous, coupled, fragile.

3.6 Operational Immaturity

The migration proceeded faster than operational tooling could keep up. Services were created without per-service CI/CD pipelines, per-service monitoring, per-service runbooks. Deploys were therefore done as a batch (because that was the only way to make the deploy tooling work). On-call was therefore shared (because per-service rotations would require per-service runbooks that didn’t exist). The result is the operational topology of a monolith on top of the architectural topology of microservices — a distributed monolith.

4. The Worst-of-Both-Worlds Problem

The most cutting framing of distributed-monolith failure is “all the costs of a distributed system, none of the benefits.” This is not hyperbole; it can be made precise.

4.1 The Costs of Distribution

Distributed systems impose a specific tax that monoliths do not pay:

• Network is unreliable. Every cross-service call can fail, time out, or be partially completed. The code must handle this — retries, timeouts, circuit breakers, idempotency. None of this exists in a monolith where all calls are in-process.
• Latency is non-zero. Every cross-service call adds milliseconds; chains of calls add tens or hundreds of milliseconds. A monolith function call is ~100 nanoseconds; a microservice HTTP call is ~1 millisecond at best (within a data center) and often 5–50ms with serialization, network, and the receiving service’s processing time. A request chain that fans out to 10 services is 100× slower than the same logic in a monolith.
• Bandwidth is finite. Cross-service traffic competes with all other traffic for the network. A monolith’s in-process calls do not.
• Partial failure is possible. Half the system can be working, the other half failing. The state of the world is no longer “up or down.” Reasoning about this is dramatically harder than reasoning about a monolith.
• Operational complexity. Service discovery, load balancing, distributed tracing, log aggregation, distributed authentication, multi-service deploys — all required to make the system work; all absent in monoliths.
• Eventual consistency. Cross-service writes cannot be a single transaction; the system is eventually consistent across services. The application code must handle this; a monolith’s single-database transaction did not require that thinking.
• Schema versioning. Cross-service contracts must be versioned because services change at different times. A monolith has one version of every contract; microservices can have multiple versions in flight.
• Distributed debugging. A bug that spans multiple services requires tracing through their logs and call graphs. A monolith bug is a stack trace.
• Increased cost. More instances, more network egress, more monitoring tools. Industry estimates put microservices at 1.5–3× the operational cost of an equivalent monolith.

A correctly-designed microservices architecture pays these costs in exchange for the benefits.

4.2 The Benefits of Microservices

A correctly-designed microservices architecture delivers:

• Independent deployability. Each service ships on its own cadence. Team autonomy is structural.
• Independent scalability. Each service is scaled to its own load profile. Cost is right-sized per service.
• Independent technology choices. Each service can use the language and framework best for its domain.
• Failure isolation. A failure in one service doesn’t take down the whole system; degradation is graceful.
• Team autonomy. Each team owns its service end-to-end. Coordination overhead is minimized.
• Bounded blast radius for changes. A change to one service is bounded in its impact; less risk per change.

These benefits are what justify the costs. A correctly-designed microservices architecture is a bargain — pay the distribution tax, get the autonomy.

4.3 The Distributed Monolith Inverts the Bargain

In a distributed monolith, the costs are paid in full. Network unreliability, latency, partial failure, operational complexity — all present, all costing engineering and operational time. But the benefits are absent. Services cannot deploy independently because of shared data and synchronous coupling; they cannot scale independently because their behavior is intertwined; they cannot fail independently because synchronous chains cascade failures; teams cannot work independently because changes require multi-service coordination.

The math is unambiguous: the team is paying premium for distribution and getting monolith-grade behavior in return. The right comparison is to a clean monolith — which would have neither the costs nor the benefits but at least would not be paying for distribution. A clean monolith outperforms a distributed monolith on essentially every operational axis: faster requests (no network hops), simpler deployments (one artifact), simpler debugging (one process), cheaper to run (one set of infrastructure), simpler to develop (one codebase, in-process calls). The only thing the distributed monolith offers over the clean monolith is the appearance of microservices — a resume credential and an architecture-diagram aesthetic, with no operational substance.

This is why some industry voices (DHH at Basecamp, Kelsey Hightower in his more inflammatory moments, the various “monolith-first” advocates) point to distributed monoliths and conclude that microservices are wrong. The honest framing: microservices are right when the bounded contexts are clear and the operational maturity exists; they are wrong when either is missing, and the failure mode of attempting them anyway is the distributed monolith.

5. Real-World Incidents and Industry Surveys

The distributed monolith is widespread. Industry surveys and post-incident reviews provide examples.

5.1 Knight Capital 2012 — Operational Fragility from a Monolith That Wasn’t Quite Modular

The Knight Capital trading firm’s 2012 disaster ($440 million loss in 30 minutes from a misconfigured trading algorithm) is technically a different failure mode (a deployment that left old code on one server) but the SEC postmortem (SEC Administrative Proceeding 70694, https://www.sec.gov/litigation/admin/2013/34-70694.pdf) describes a system that was nominally distributed (multiple servers running components) but operationally monolithic — components deployed in lockstep, no per-server kill switch, shared assumptions about which code was where. This is the distributed-monolith failure pattern in its most catastrophic form: the system’s distribution gave the appearance of resilience without the substance.

5.2 The “Microservices Migration That Produced a Distributed Monolith”

Anonymous case studies abound; specific organizations rarely publicize the failure. The pattern that recurs in conference talks (QCon, GOTO, microXchg, etc.) and architecture-blog post-mortems:

1. Company X has a 10-year-old Rails monolith. It’s painful — long deploys, poor scaling, etc.
2. Company X commits to a microservices migration.
3. Two years later, Company X has 50+ services, all sharing a Postgres database, all deployed every Friday, with deploy times now 4 hours instead of 30 minutes.
4. Engineering org notices that the migration has not delivered the promised benefits. Several engineers blog about it; others present at conferences.
5. Company X starts a remediation project (“the great database split”) that takes another 18 months.

This pattern has been reported by multiple companies in the 2018–2024 period across e-commerce, SaaS, fintech, and travel. The remediations are expensive and partial; few companies emerge from a distributed-monolith migration with a clean microservices estate.

5.3 Shopify’s Counter-Example — Modular Monolith

Shopify deliberately chose not to migrate to microservices, instead investing in a modular monolith architecture (https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity, 2019). They kept the deploy as a single Rails application but enforced strict module boundaries within the codebase, with explicit contracts between modules and tooling that prevented cross-module dependencies that violated the boundaries. The result: the developer-productivity benefits that microservices were supposed to provide (clear module boundaries, team autonomy within modules), without the operational cost of distribution. Shopify’s blog post is widely cited as the canonical “you don’t have to do microservices to get the benefits” reference.

The Shopify example is important specifically because it shows the distributed-monolith failure was not inevitable. The decomposition discipline (clear module boundaries, contracts between modules) is what produces the benefits; the deployment topology (one process or many) is a separate decision.

5.4 Newman 2021 Survey Data

Sam Newman’s Building Microservices (2nd ed., 2021) cites informal industry surveys suggesting that a majority of organizations describing themselves as having “microservices” are actually running distributed monoliths by the strict definition (services that cannot be deployed independently). The exact percentage varies by survey — 50–70% is a typical range. The qualitative observation: even at organizations with strong engineering brands, the strict definition of microservices is rarely fully achieved; most settle for “we have services” without “we can deploy them independently.”

6. How to Recognize — Diagnostics

Concrete metrics and analyses that surface the pattern:

Deploy independence ratio. Take the last 30 days of deploys; for each service, count the number of deploys that included only that service (independent) versus included multiple services (coordinated). Compute the ratio. Healthy microservices: independent deploys are >90% of all deploys. Distributed monolith: independent deploys are <10% of all deploys.

Cross-service test surface. Compute the percentage of test wall-clock time spent on tests that exercise multiple services. Healthy microservices: <20%. Distributed monolith: >60%.

Database access map. For each database table, list the services that have read access and write access. Healthy microservices: each table is accessed by exactly one service. Distributed monolith: most tables are accessed by 3+ services.

Synchronous call graph depth. For a representative customer request, trace the synchronous call graph. Count the maximum depth (longest chain of synchronous calls before the response is returned). Healthy microservices: 2–3 levels deep. Distributed monolith: 5+ levels deep, with fan-outs at each level.

Shared deployment cadence. For each service, measure the deploy cadence (deploys per week). Compute the variance across services. Healthy microservices: high variance (some services ship daily, others weekly). Distributed monolith: low variance (every service ships on the same Friday cadence).

Failure correlation. Look at incidents over the last quarter. For each incident, count the number of services impacted. Healthy microservices: most incidents impact 1 service. Distributed monolith: most incidents impact 5+ services because the synchronous chains cascade.

Schema-migration coordination cost. Time how long the average database schema migration takes from “PR opened” to “deployed in production.” Healthy microservices: hours to a day. Distributed monolith: days to weeks because of cross-service coordination.

API contract stability. Measure the frequency of breaking changes to inter-service APIs. Healthy microservices: rare; consumers migrate on their own schedule. Distributed monolith: frequent; every contract change forces lockstep deploys.

If 4 or more of these metrics are in the distributed-monolith range, the diagnosis is essentially confirmed.

7. How to Fix — The Remediation Playbook

Resolving a distributed monolith is multi-quarter work. There is no quick fix; the underlying coupling must be reduced step by step. The remediation playbook, derived from Newman 2021, Richardson 2018, and accumulated industry experience:

7.1 Re-Establish Data Ownership Boundaries

The shared database is usually the foundational coupling. Resolving it requires:

1. Map current data access. For each table, list which services read and write. This is the audit step.
2. Choose a single owner per table. For each table, decide which service owns it. The owner is the only service with direct write access; all other services access via the owner’s API.
3. Migrate non-owners off direct access. For each table, identify the non-owner services that currently access it. Move them to API calls through the owner. This may take a service at a time over several quarters.
4. Consider physical separation. Once logical ownership is established, consider moving the table to a separate database instance owned by the owner service. This makes the boundary harder to violate going forward.

This step is the largest in the remediation; it can take 6–18 months for a moderately-sized estate. It is also the step that pays the most because the shared database is the strongest coupling.

7.2 Introduce Asynchronous Messaging

Services that currently communicate exclusively via synchronous HTTP need an asynchronous channel for events. Add a message bus or event log (Event-Driven Architecture, Distributed Log System Design) and migrate cross-service workflows that don’t strictly need synchronous responses to events.

A typical pattern: the order-placement flow currently involves the OrderService synchronously calling InventoryService, PaymentService, and ShippingService and waiting for all of them. Migrate to: OrderService commits the order locally, publishes OrderPlaced event; Inventory, Payment, Shipping consume the event independently and react asynchronously. The synchronous chain is broken; services can fail, scale, and deploy independently.

This step reduces the synchronous call-graph depth and gives services genuine independent failure domains. It usually requires introducing the messaging infrastructure (Kafka, RabbitMQ, AWS SQS) if not present; this is its own engineering effort.

7.3 Enable Independent Deployment Via Feature Flags and Contract Testing

Services need to be able to ship independently. This requires:

• API versioning. When service A changes its response, it does so by adding a v2 endpoint that coexists with v1 for a deprecation window. Consumers migrate when they’re ready.
• Contract testing. Services publish their API contract (e.g., via Pact, OpenAPI spec); consumers verify against the contract independently. Cross-service integration testing becomes an exception, not the default.
• Feature flags for coordinated rollouts. When a feature does require coordinated changes across services, use feature flags to turn the feature on for all services after they are all deployed. The feature toggle replaces the deployment coordination.
• Backwards-compatible schema migrations. Use the Expand-Contract Pattern: add new columns/tables alongside old ones, migrate consumers, then remove old.

These practices, taken together, allow services to deploy at their own cadence. The team’s deploy frequency per service should rise dramatically.

7.4 Re-Team Around Bounded Contexts

If the underlying organizational structure is the cause (Conway’s Law), addressing it requires re-teaming. Identify the bounded contexts in the domain; assign each to a team; let the team own the corresponding services end-to-end.

This is operationally and politically expensive. It is also often the only way to truly resolve the distributed monolith because if the team boundaries don’t match the service boundaries, the coordination overhead never goes away.

7.5 Sometimes the Right Answer is Re-Consolidate

The most controversial remediation answer: sometimes the right call is to re-consolidate a distributed monolith back into a Monolithic Architecture (or modular monolith). This is the right answer when:

• The bounded contexts genuinely are not clear and trying to find them is producing thrash.
• The team’s operational maturity does not support multiple independently-deployable services.
• The system size and load do not justify the operational overhead of distribution.
• The team is small enough that one deploy cadence is fine.

Re-consolidation is taboo in many engineering cultures because it feels like “going backwards.” In practice, going backwards to a clean monolith and then extracting services as bounded contexts become clear is dramatically more effective than continuing forward with a distributed monolith. Several companies (notably Stack Overflow, which is famously a monolith; some sub-teams at GitHub; many smaller startups) have publicly described re-consolidation moves and credited them with productivity gains.

The decision to re-consolidate is essentially: “we paid the microservices tax and we are not getting the benefits; let’s stop paying the tax.” It requires emotional courage from leadership but is a sound technical answer in many cases.

7.6 Apply Strangler Fig Internally

The Strangler Fig Pattern (Fowler’s name for incremental replacement) is usually framed as monolith-to-microservices. It applies equally to distributed-monolith-to-clean-microservices. The pattern: identify a bounded context; build a new service for it (or a new module within the consolidated monolith); route traffic gradually from the old tangled services to the new one; once all traffic is on the new service, retire the old. Repeat for each bounded context.

The internal Strangler Fig is essentially “rebuild the right architecture incrementally without breaking the system.” It is the pragmatic, low-risk path through remediation. It is also slow; expect 18–36 months for a substantial remediation.

8. Worked Example — A 50-Service E-Commerce Distributed Monolith

To anchor the pattern in a concrete scenario:

The setting. An e-commerce company migrated from a Rails monolith to “microservices” between 2018 and 2020. The result is 50 services, all in Go, all deployed via a single CI pipeline. The services include: OrderService, InventoryService, ProductService, UserService, AddressService, PaymentService, ShippingService, FulfillmentService, NotificationService, EmailService, AuditService, PromotionService, CartService, CheckoutService, … (and so on, fine-grained per entity).

The diagnosis. Apply the §6 diagnostics:

• Deploy independence ratio. 5%. Most deploys are coordinated weekly Friday releases of all 50 services.
• Cross-service test surface. 70%. The integration test suite, which spans 30+ services in some test paths, takes 4 hours per run.
• Database access map. A single Postgres instance with ~200 tables. The “inventory” table is read by OrderService, CheckoutService, FulfillmentService, ShippingService and written by InventoryService and OrderService. Most tables have 3+ services accessing them.
• Call graph depth. The customer “place order” request synchronously fans out: OrderService → InventoryService (check stock) → ProductService (price lookup) → UserService (eligibility) → PromotionService (promotion check) → AddressService (shipping calc) → ShippingService (rate quote) → PaymentService (auth). Eight services in a synchronous chain; 800ms p99 latency just for the network hops.
• Failure correlation. When ShippingService is down for routine maintenance, OrderService cannot complete checkouts. When PaymentService is slow, OrderService queues fill and tip over. Most incidents impact >10 services.
• Schema-migration coordination cost. A typical column rename takes 3 weeks: 1 week of coordination (which services need updates), 1 week of deploys (each service updated individually), 1 week of cleanup (removing old column).

The breaking event. A flash-sale event (Black Friday) overwhelms the system. The InventoryService is the bottleneck; its DB queries on the shared Postgres are slow because the writes from OrderService are also hitting the same instance. The synchronous chain’s latency cascades; OrderService timeouts; customers see failed checkouts; revenue impact is significant.

The remediation. The architecture team commits to a 24-month remediation:

1. Months 1–3: Audit and triage. Map every table’s access pattern. Identify the worst offenders (the inventory table, the user table, the order table). Establish ownership: InventoryService owns inventory, UserService owns users, OrderService owns orders.

2. Months 3–9: Database split, phase 1. Move the inventory table to a dedicated Postgres instance owned by InventoryService. All other services lose direct access; they call InventoryService’s API instead. This requires updating every service that touched inventory; the work is parallelized across teams. The synchronous chain becomes longer initially (more API calls instead of direct DB reads) but the coupling is now explicit and versionable.

3. Months 6–12: Introduce Kafka for asynchronous events. Stand up a Kafka cluster. Migrate the OrderPlaced workflow from synchronous fan-out to event-based: OrderService commits the order, publishes OrderPlaced; InventoryService, ShippingService, EmailService consume independently. The synchronous call graph shrinks to OrderService → PaymentService (the only synchronous step required for the checkout response) and everything else becomes asynchronous.

4. Months 9–15: Re-consolidate over-decomposed services. The fine-grained services (AddressService, PromotionService, CartService) are folded into their natural owners (UserService, PromotionService remains but with a clearer scope, OrderService absorbs CartService). The total service count drops from 50 to 25. Each remaining service has a coherent bounded context.

5. Months 12–18: Database split, phase 2. Move user and order tables to dedicated instances owned by their respective services. By now most services have been weaned off direct database access; this step is incremental.

6. Months 18–24: Independent deployment infrastructure. Per-service CI/CD pipelines; per-service monitoring; per-service on-call. Deploys move from weekly batch to per-service ad-hoc. By the end, the deploy independence ratio has risen from 5% to 80%.

The result after 24 months: 25 services, each with its own database, communicating via a mix of synchronous APIs (for read paths needing strong consistency) and asynchronous events (for write workflows). Deploy independence is restored. Failure isolation is restored. The team finally gets the microservices benefits they were promised in 2018, six years late.

This example is a composite of real patterns; specific details vary by company. The pattern is consistent: remediation is multi-year, involves both architectural and organizational change, and frequently includes some service consolidation alongside the data-ownership restoration.

8.7 Remediation Flow Diagram

flowchart TD
    Start[Diagnose: distributed monolith confirmed] --> Audit[Audit data ownership and call graph]
    Audit --> Decide{Remediation strategy}
    Decide -->|"clear bounded contexts exist"| Forward[Move forward: split data + add async messaging]
    Decide -->|"contexts unclear or team small"| Backward[Re-consolidate to modular monolith]
    Decide -->|"hybrid"| Mixed[Consolidate over-decomposed; split under-decomposed]
    Forward --> SplitDB[Phase 1: establish data ownership; split DB tables]
    SplitDB --> AddMsg[Phase 2: introduce async messaging for cross-service workflows]
    AddMsg --> IndepDeploy[Phase 3: enable independent deployment via versioning + flags]
    IndepDeploy --> ReTeam[Phase 4: re-team around bounded contexts]
    ReTeam --> Done[Healthy microservices estate]
    Backward --> ConsolidateBatch[Consolidate services into modular monolith]
    ConsolidateBatch --> EnforceModularity[Enforce module boundaries with tooling]
    EnforceModularity --> Done2[Modular monolith - extract later as needed]
    Mixed --> Done

What this diagram shows. The remediation flow begins with diagnosis confirmation; the next decision is the strategy. If bounded contexts are clear, the team can move forward — splitting data ownership, adding asynchronous messaging, enabling independent deployment, and finally re-teaming. If contexts are unclear or the team is too small, re-consolidation to a modular monolith is the right answer; later, individual contexts can be re-extracted as they become clear. The hybrid path consolidates over-decomposed services while splitting under-decomposed ones — common in mixed-state estates. The diagram emphasizes that “remediation” is not a single path; the right strategy depends on the team’s current understanding of the domain, the size of the engineering organization, and the operational maturity available.

9. Comparison with Proper Microservices Architecture

To sharpen the contrast:

Property	Proper Microservices	Distributed Monolith
Service deploys per week	High variance per service; some daily, some monthly	Uniform; all services deploy on the same cadence
Database ownership	One service owns each table; others access via API	Many services access the same tables directly
Cross-service communication	Mix of sync (read paths needing consistency) and async (write workflows)	Predominantly synchronous request-response
Failure isolation	Service outages do not cascade; graceful degradation	Service outages cascade; whole system goes down
Schema changes	Backwards-compatible; consumers migrate on their schedule	Requires lockstep coordination across all consumers
Test surface	Per-service tests + contract tests; cross-service tests rare	Heavy cross-service integration tests required for any change
Team autonomy	Each team owns its service end-to-end	Cross-team coordination required for any meaningful change
Operational cost	Higher than monolith; justified by autonomy	High (because distributed) without the autonomy benefit
Latency profile	Some hops, designed for; mostly fast paths	Long synchronous chains; high p99 latency
Resilience	Designed in: circuit breakers, bulkheads, retries	Brittle: every dependency is a single point of failure

The most important rows are deploy independence and failure isolation. These are the two operational behaviors that distinguish microservices from monoliths. A proper microservices architecture has both; a distributed monolith has neither.

9.1 Cost Comparison — Quantifying the Difference

A useful framing: imagine three architectures running the same business logic — a clean monolith, healthy microservices, and a distributed monolith. The relative operational costs:

Cost dimension	Clean Monolith	Healthy Microservices	Distributed Monolith
Infrastructure cost	1.0× (baseline)	1.5–3×	2–4×
Engineering cost per feature	1.0×	1.0–1.5×	2–3×
Mean time to deploy	5–30 minutes	5–15 minutes per service	1–4 hours
Mean time to recover	5–30 minutes	5–15 minutes per service	30–120 minutes
On-call burden	Low (one rotation)	Distributed (per-service)	High (cross-service)
Onboarding time for new engineers	2–4 weeks	2–4 weeks per service	6–12 weeks
Bug-fix turnaround	Hours to days	Hours to days	Days to weeks
Schema migration time	Single PR, hours	Per-service, hours	Cross-team, weeks

The distributed monolith is consistently the worst of the three on most dimensions. The clean monolith and healthy microservices are roughly comparable on engineering cost per feature, with the monolith winning on infrastructure cost and the microservices winning on team-autonomy benefits. The distributed monolith costs more on every dimension because it bears infrastructure cost of distribution plus engineering cost of coordination.

This is why the architectural dictum “microservices or monolith — but never distributed monolith” makes economic sense. The middle ground is more expensive than either extreme.

10. Connection to Sibling Anti-Patterns

The distributed monolith is part of a family of architectural anti-patterns that describe specific failure modes:

• Big Ball of Mud Anti-Pattern — the in-process tangle. The distributed monolith is essentially the cross-process version of this: a Big Ball of Mud spread across a network. Verraes 2014 explicitly drew the connection with “Distributed Big Ball of Mud.”
• Shared Database Anti-Pattern — usually the foundational coupling that makes a system a distributed monolith. Eliminating the shared DB is usually step 1 of remediation.
• God Object Anti-Pattern — sometimes the distributed monolith has a “god service” that everything else depends on; this combines with shared DB to produce maximally fragile architecture.
• Spaghetti Architecture — the call-graph topology where every service can call every other service, with no clear hierarchy or layering. Often present in distributed monoliths.
• Anemic Domain Model — services that are pure data containers without behavior, with logic in callers; produces tight contract coupling.

The connections are mostly causal: shared database leads to shared deployment leads to distributed monolith; god services intensify the coupling; spaghetti call graphs are the runtime topology of the same problem. Resolving one anti-pattern usually requires resolving several.

10.1 Sibling-Pattern Co-Occurrence Patterns

The anti-patterns rarely appear alone. Common co-occurrence clusters:

The “post-migration mess” cluster. Distributed Monolith + Shared Database + Big Ball of Mud. The team migrated from a monolithic Big Ball of Mud to “microservices” without resolving the underlying tangling. The shared database persists; the call graph remains synchronous; the muddy logic is now spread across multiple services. This is the most common cluster after failed microservices migrations and the most expensive to remediate because all three patterns reinforce each other.

The “god service centric” cluster. Distributed Monolith + God Service. One service handles most cross-cutting concerns; every other service depends on it for various capabilities; the god service’s deploy and on-call cadence dominates the estate. Eliminating the god service is the highest-leverage step; it’s also the politically hardest because the god service often has the most senior engineers and the most institutional knowledge.

The “premature distribution” cluster. Distributed Monolith + over-decomposition. The team split too small — services per entity, services per technical layer — and the result is many tiny services that constantly need each other. The remediation is partial re-consolidation: merge fine-grained services into bounded-context-shaped services. This is a less common cluster but recurs in teams that took the “microservices = many small services” message too literally.

The “dependent estate” cluster. Distributed Monolith + chains of synchronous RPC. No god service; no single shared database; but every customer-facing operation traverses 7+ services synchronously. Failures cascade because the call graph has no fault isolation. The fix is asynchronous messaging for non-critical-path operations and circuit breakers for critical-path ones.

Recognizing the cluster shape informs remediation priorities: clusters that include shared database start with database split; clusters with god service start with god decomposition; clusters with chains start with async messaging.

11. Common Interview Discussion Points

• “What is a distributed monolith?” A system that looks like microservices (multiple deployable services, network communication) but behaves like a monolith (services cannot deploy independently, share data through shared DBs, fail together). Has all the costs of distribution and none of the benefits.
• “How do you recognize one?” Deploy independence ratio (most services ship in lockstep weekly), shared database (multiple services accessing the same tables), high cross-service integration test surface, synchronous call chains 5+ levels deep, failure cascades from any single service.
• “Why does it happen?” Adopting microservices without bounded contexts; decomposition along wrong seams (technical layers, entities, team boundaries); shared database forced shared deployment; synchronous-only communication; operational immaturity; Conway’s Law producing tangled services from tangled organizations.
• “How do you fix it?” Re-establish data ownership (eliminate shared DB); introduce asynchronous messaging; enable independent deployment via versioning + feature flags; re-team around bounded contexts; sometimes re-consolidate to monolith. Multi-quarter work.
• “Should we always avoid distributed monoliths?” Yes, but the real question is “should we always do microservices?” — to which the answer is no. If you don’t have the prerequisites (clear bounded contexts, operational maturity), a clean monolith is better than a distributed monolith.
• “What’s the difference between distributed monolith and modular monolith?” Modular monolith = one deployable unit with strict internal modules and contracts (Shopify). Distributed monolith = multiple deployable units with no strict contracts and lots of coupling. Modular monolith is good architecture; distributed monolith is bad architecture.
• “How does this connect to Conway’s Law?” Conway: architecture mirrors org structure. If your org has tangled team boundaries, your microservices will have tangled service boundaries — which is a distributed monolith. The fix is the Inverse Conway Maneuver: re-organize teams to match the desired architecture.

11.1 Story Arc — How to Discuss Inheriting a Distributed Monolith

A common interview scenario: “Tell me about a time you inherited a distributed monolith. How did you approach it?” The strong answer has a specific shape:

Recognition. Describe the diagnostic process — what signs you observed, what metrics you measured, how you confirmed the diagnosis. “Deploys took 3 hours and were always all-services-at-once; the database had connections from every service hostname; outage of the order service brought down checkout; cross-service joins were in code in 12 places.”

Diagnosis communication. How you explained the situation to leadership and the team. The diagnosis is politically sensitive — the team that built the system feels criticized. “I framed it not as ‘this was wrong’ but as ‘we paid the cost of distribution but didn’t get the benefit; here’s how we capture the benefit.’ The team responded better than expected because the framing was about future capability, not past blame.”

Strategy. The remediation strategy you chose and why — including alternatives considered and rejected. “We considered re-consolidating to a modular monolith but the team had grown to 80 engineers; the modular monolith would have collapsed under that scale. We chose to fix the distribution rather than reverse it.”

Sequencing. The order in which you tackled remediation steps and why. “We started with the shared database split because every other change was bottlenecked on it. Specifically the inventory table because that was the one causing flash-sale incidents.”

Outcome. The measurable outcome — what improved, what didn’t, what surprised you. “After 14 months, deploy independence was 75% (from 5%); MTTR dropped from 90 minutes to 25; engineer satisfaction surveys showed substantial improvement.”

This story arc demonstrates: ability to diagnose, ability to communicate, strategic thinking, technical execution, measurement discipline. It is what senior-engineering interviews look for in this question.

12. Pitfalls

Pitfall 1: confusing “we have services” with “we have microservices.” The service count is not the metric. The metric is deploy independence and failure isolation. A team can have 50 services that are a distributed monolith or 5 services that are healthy microservices. Don’t measure architecture by service count.

Pitfall 2: continuing the migration without addressing the cause. If the migration produced a distributed monolith, doing more of the same will not fix it. The remediation requires addressing the underlying coupling (shared data, missing bounded contexts, synchronous-only communication) — not just adding more services.

Pitfall 3: treating the diagnosis as criticism rather than as actionable. “Distributed monolith” sounds pejorative and triggers defensiveness. The diagnosis is useful only if the team can take it as data and act on it; treating it as an attack on the team’s competence delays remediation. Frame the remediation as an evolution from one architecture to another, not as fixing a mistake.

Pitfall 4: re-consolidation without addressing decomposition issues. Re-consolidating a distributed monolith into a regular monolith without enforcing module boundaries produces a Big Ball of Mud Anti-Pattern — a tangled in-process system. Re-consolidation must be to a modular monolith with explicit boundaries; otherwise the team will end up with the same coupling problems in a single process.

Pitfall 5: addressing symptoms instead of causes. Adding circuit breakers to mask the synchronous-coupling problem; adding integration tests to catch the deploy-coordination problem; adding more aggressive monitoring to handle the cascading-failure problem. These treat symptoms; the cause is the underlying coupling and that must be addressed structurally.

Pitfall 6: assuming all microservices migrations end up as distributed monoliths. Some are healthy (Netflix, Uber, Stripe). The pattern is a failure mode, not an inevitability. The question is whether the prerequisites were met (bounded contexts, operational maturity), not whether the architecture style was attempted.

Pitfall 7: rebuilding without deeper understanding of the domain. The remediation often requires re-decomposing the system; if the team doesn’t understand the domain better the second time around, the new decomposition will have the same flaws. Invest in domain understanding (event storming, context mapping) as part of remediation, not just code refactoring.

Pitfall 8: cargo-culting the fix. “We need Kafka because everyone says so.” Adopting messaging infrastructure without understanding what cross-service workflows should be asynchronous produces no architectural improvement; it just adds infrastructure. The asynchronous messaging step is meaningful only if specific workflows are migrated to async patterns (events, sagas).

Pitfall 9: under-estimating the time and political capital required. Remediations are 18–36 months. They require leadership buy-in for multiple quarters. Teams that start a remediation, lose momentum, and revert end up with a partially-remediated distributed monolith — in some ways worse than the original because the half-state has its own pathologies.

Pitfall 10: not measuring progress. Without metrics like deploy-independence ratio and call-graph depth, the team cannot tell whether the remediation is working. Measure these continuously throughout the remediation; declare victory only when the metrics are healthy.

Pitfall 11: assuming all services need to be split equally. Some services were correctly extracted; some were wrongly extracted; some were never extracted but should be. The remediation must triage — not every service is equally problematic. Some may be candidates for re-consolidation; others for further extraction; others fine as-is. Treating every service uniformly wastes effort and may make some services worse.

Pitfall 12: the “we’ll never use microservices again” overcorrection. After a painful distributed-monolith experience, some teams swing to “monoliths only, microservices are evil.” This is the wrong lesson. Microservices are the right architecture in some contexts; the failure was in execution, not in choice. The right lesson is “microservices require specific prerequisites; without them, monolith is better.” The architecture choice should remain context-dependent, not become dogmatic in either direction.

Pitfall 13: skipping the operational maturity prerequisite. Some teams attempt remediation while still lacking the basic operational tooling (per-service CI/CD, monitoring, distributed tracing). Without these, even a remediated architecture becomes another distributed monolith because operational practices haven’t caught up. Build the tooling alongside the remediation; treat them as a single project.

13. Open Questions

• Is there a quantitative metric that reliably predicts when a microservices estate has become a distributed monolith? Several individual metrics (deploy independence, call-graph depth, database access map) have value but no single composite metric is universally accepted.
• At what team size and engineering maturity does the cost-benefit math of microservices favor the architecture? Industry rules of thumb (50+ engineers, 5+ teams) exist but are noisy.
• How should the Inverse Conway Maneuver be sequenced for distributed-monolith remediations — re-team first, then re-architect, or vice versa? Practitioners disagree; both sequences have produced successes and failures.
• Are there architectures intermediate between modular monolith and microservices that capture more of the benefit at less cost? The “macroservices” or “self-contained systems” patterns are sometimes proposed but not widely adopted.
• How do AI-assisted refactoring tools change the remediation economics? Lower-cost extraction may make remediation more affordable; the limit may be domain understanding, not engineering effort.
• Is there a software analogue of “minimum viable architecture” — the smallest system size that should be built as microservices versus a monolith? Empirical guidance exists but is contested.

14. See Also

• Microservices Architecture — the architecture style the distributed monolith fails to actually achieve
• Monolithic Architecture — the original starting point; sometimes the right destination after remediation
• Service-Oriented Architecture — the predecessor architecture style; SOA had its own analogue (“ESB monolith”)
• Event-Driven Architecture — the asynchronous communication style that helps break sync coupling
• Event Sourcing Pattern — durable events as the source of truth; supports decoupled architecture
• Distributed Log System Design — Kafka-class infrastructure for the async messaging step
• Publish Subscribe System Design — alternative messaging substrate
• Big Ball of Mud Anti-Pattern — the in-process tangle; distributed monolith is its cross-process cousin
• Shared Database Anti-Pattern — the most common foundational coupling in distributed monoliths
• God Object Anti-Pattern — when one service dominates the others; intensifies the distributed-monolith pathology
• Saga Pattern — replaces distributed transactions in a properly-decoupled architecture
• Strangler Fig Pattern — the incremental remediation approach
• Domain-Driven Design Strategic Patterns — bounded contexts as the right service boundaries
• Architecture Decision Records — document remediation decisions; chain shows the architectural evolution
• Conway’s Law — the organizational dynamic that shapes service boundaries
• Circuit Breaker Pattern — resilience primitive that proper microservices use
• Bulkhead Pattern — failure isolation primitive
• API Versioning — the discipline that enables independent deployment
• Modular Monolith — the alternative architecture for teams not ready for microservices
• Outbox Pattern — reliable cross-service event publication
• Change Data Capture — supports database-split migrations
• Event Notification vs Event-Carried State Transfer — explicit pattern choice prevents distributed-monolith drift
• Idempotency in Distributed Systems — required for asynchronous decoupling
• Two-Phase Commit — what proper microservices avoid via Saga
• System Architectures MOC
• SWE Interview Preparation MOC