A distributed monolith is a system that has been physically split into many independent‑looking services, but is still logically wired together so tightly that it behaves like one giant, solid block.

Picture a toy castle built out of LEGO blocks. Every block is locked to the block next to it, so moving a single wall means lifting ten walls at once. Now imagine someone tells you, “Don’t worry, I split your castle into 10 separate small castles.” But when you look closely, all ten castles are still glued together with invisible strings. You can paint them different colours, put them in different rooms, and give them different names — but if you touch one, the others still shake.

That “glued together but pretending to be separate” castle is exactly what engineers call a distributed monolith. It is one of the most talked‑about problems in modern software architecture, and almost every large engineering team has built one by accident at least once.

What does the term mean, word by word?

Breaking the term into two words makes the whole idea click into place.

So a distributed monolith is a contradiction that somehow exists in real life: a system that has been physically split into many independent‑looking services (microservices, on the surface), but whose services are so tightly wired to each other that they behave like one giant, solid block. You inherit every downside of a distributed system — network calls, more servers to manage, more places for things to break — without earning any of the upside a distributed system is supposed to give you (services that can change, deploy, and fail independently).

A short history: how did we get here?

To understand why distributed monoliths exist, it helps to trace the way software architecture has evolved.

The term “distributed monolith” spread widely around 2015–2017, when companies that adopted microservices too quickly — without changing team structure or coupling habits — discovered they now had more operational pain (deployments, network calls, cross‑service debugging) with none of the promised independence. Architects such as Martin Fowler and Sam Newman (author of Building Microservices) wrote extensively about the anti‑pattern as a warning to the industry.

Why should you care?

The distributed monolith is one of the most commonly discussed failure patterns in system‑design interviews, real production incidents, and architecture reviews. Understanding it deeply will help you:

• Recognise the warning signs early in your own projects.
• Answer system‑design interview questions with real depth instead of buzzwords.
• Avoid multi‑year, multi‑million‑dollar re‑architecture projects caused by this mistake.
• Make better decisions about when to split a monolith into services — and when not to.

Distributed monoliths are what happens when a team performs the physical split into services but forgets the logical one — the services still call each other constantly, share the same database, and must be deployed together for anything to work.

Why teams started splitting monoliths in the first place

Before diagnosing the distributed monolith, it helps to remember why anyone wanted to break monoliths apart at all. A traditional monolith is a single application containing everything — user‑interface logic, business rules, database access — compiled and deployed as one unit.

As companies grew, monoliths caused three big pains:

1. 1. Slow deployments

   Every small change required rebuilding and redeploying the entire application. A one‑line bug fix in the payments module meant redeploying search, profile, and checkout too.

2. 2. Team collisions

   Hundreds of engineers pushing code into one shared codebase caused constant merge conflicts and “who broke the build?” arguments.

3. 3. Scaling waste

   If only the video‑streaming part of Netflix needed more servers, the entire monolith still had to be scaled — wasting money on parts that didn’t need capacity.

The proposed fix was microservices: break the one big application into many small, independent services. Each service should own its own code, its own database, and its own deployment pipeline. In theory, teams could then deploy independently, scale independently, and even use different programming languages for different services.

Where it goes wrong: the birth of the distributed monolith

Here is the core problem. Many teams performed only the physical split — moving code into separate repositories, separate servers, and separate deployment pipelines — but they did not perform the logical split. The services still called each other constantly, shared the same database tables, and had to be deployed together in a specific order for anything to work.

The motivation to study this deeply

This topic deserves careful attention because it is invisible until it hurts. A team can build a distributed monolith for two years, feel proud of having “20 microservices,” and only discover the truth during a painful incident: one Friday‑night deployment of Service C breaks Services A, B, D, and E, because they were never really independent. Understanding the anatomy of the problem lets you spot it in a code review, in an architecture diagram, or in an interview — long before it becomes a 3 a.m. outage.

A short, precise vocabulary you will meet again in interviews, in code reviews, and in production war stories about what went wrong.

3.1 Coupling

What it is: how much one piece of code depends on the internal details of another piece of code. High coupling means changing one thing forces you to change another; low coupling means pieces can change independently.
Why it exists as a concept: engineers needed one word to measure “how tangled” a system is, so they can predict how expensive future changes will be.
Where it is used: every area of software design, from a single function calling another to services calling each other across a network.

3.2 Cohesion

What it is: how well the responsibilities inside one module or service belong together. High cohesion means a service does one clear job well.
Why it exists: a good service boundary groups things that change together for the same business reason, and separates things that change for different reasons.

3.3 Service Boundary

What it is: the line that decides what belongs inside a service versus outside it — the “walls” of a service.
Why it exists: without clear boundaries, teams do not know where to put new code, which leads to overlap and duplicated logic.

3.4 Synchronous vs. Asynchronous Communication

What it is: synchronous communication means Service A calls Service B and waits for the answer before continuing (like a phone call). Asynchronous communication means Service A sends a message and continues its own work without waiting (like sending a text message).
Why it exists: different tasks need different guarantees. Some need an immediate answer (checking if a credit card is valid); others can happen eventually (sending a receipt email).

3.5 Shared Database Anti‑pattern

What it is: two or more “independent” services read and write to the same database tables.
Why it’s a problem: it secretly re‑creates a single point of coupling. Even if the application code is split, the data layer is not, so schema changes still require coordinating across every team.

3.6 Deployment Coupling

What it is: Service A and Service B must be deployed together, or in a specific order, for the system to work.
Why it matters: true microservices should be deployable in any order, at any time, independently. Writing a runbook like “deploy Service B first, wait 5 minutes, then deploy Service A” is a hallmark of the distributed monolith.

3.7 Contract (API Contract)

What it is: the agreed shape of a request and response between two services — a promise: “if you send me this shape of data, I will return you this shape of data.”
Why it exists: contracts let two teams work independently as long as both honour the same agreed shape, similar to plugging any lamp into a standard electrical socket.

3.8 Backward Compatibility

What it is: a new version of a service that still works correctly with older clients or older versions of other services that have not upgraded yet.
Why it exists: in a real distributed system, you cannot upgrade every service at the exact same second. Backward compatibility lets you upgrade one service at a time, safely.

3.9 CAP Theorem (brief)

What it is: a rule stating that a distributed data system can fully guarantee only two of three properties at once: Consistency (everyone sees the same data), Availability (every request gets a response), and Partition Tolerance (the system keeps working when network connections break).
Why it matters here: distributed monoliths often ignore CAP trade‑offs because they assume the network between services is always fast and always available — an assumption that fails in real production networks.

The moving parts that make up a system drifting into a distributed monolith — compared, piece by piece, to a healthy microservices architecture.

4.1 The typical (broken) architecture

4.2 Component breakdown

4.3 The healthy version, for comparison

Zoom into exactly how a single request behaves inside a distributed monolith, step by step, and compare it with a properly decoupled system.

5.1 Step by step: a single “Place Order” request inside a distributed monolith

1. 1. Client sends “Place Order” to the API Gateway.

   Nothing unusual so far — every architecture starts here.

2. 2. Gateway forwards it to the Order Service.

   Also normal — the gateway routes based on URL or client.

3. 3. Order Service makes a synchronous HTTP call to Inventory Service to check stock, and waits.

   First blocking hop.

4. 4. Inventory Service, before answering, makes its own synchronous call to Warehouse Service to double‑check physical stock, and waits.

   Second blocking hop, nested inside the first.

5. 5. Once Warehouse replies, Inventory replies to Order.

   The chain unwinds one level.

6. 6. Order Service now calls Payment Service synchronously, and waits.

   Third blocking hop.

7. 7. Payment Service calls a Ledger Service to record the transaction, and waits.

   Fourth blocking hop.

8. 8. Only after all of this succeeds does Order Service write to the shared database and reply to the client.

   The client has been waiting the entire time.

Notice the pattern: one single request now depends on the health, speed, and availability of six components in a straight chain. If Warehouse takes four extra seconds to respond, or briefly goes down, the entire “Place Order” flow slows down or fails — even though the client only cares about Order and Payment.

5.2 The same flow, done in a healthy, decoupled way

1. 1. Client sends “Place Order.”

   Same trigger as before.

2. 2. Order Service checks a locally cached or eventually‑consistent view of stock, records the order as “pending,” and immediately replies “Order received” to the client.

   No blocking call to another service is needed for the common case.

3. 3. Order Service publishes an OrderCreated event to a message broker.

   The event is durable — if anyone downstream is momentarily unavailable, it will still be delivered.

4. 4. Inventory, Payment, and Shipping Services each independently listen for the event and process it at their own pace.

   They no longer form a chain — they work in parallel.

5. 5. If Payment fails, Payment publishes a PaymentFailed event; Order Service reacts by marking the order as failed and notifying the customer — without ever having been “stuck waiting.”

   Failure is a first‑class message, not a blocked call.

5.3 Java example: tight coupling vs. loose coupling

Below is a small, realistic Java example showing the difference. First, the tightly coupled (distributed‑monolith) style, where Order Service directly and synchronously calls other services and cannot proceed without them:

// Blocking calls: if any dependency is slow or down, the client waits.
public class OrderService {

    private final InventoryClient inventoryClient; // HTTP client to Inventory
    private final PaymentClient   paymentClient;   // HTTP client to Payment

    public OrderService(InventoryClient inventoryClient, PaymentClient paymentClient) {
        this.inventoryClient = inventoryClient;
        this.paymentClient   = paymentClient;
    }

    public OrderResult placeOrder(OrderRequest request) {
        // Step 1: blocking call - if Inventory Service is down, this throws.
        boolean inStock = inventoryClient.checkStock(request.getItemId());
        if (!inStock) {
            throw new OutOfStockException("Item not available");
        }

        // Step 2: blocking call - if Payment Service is slow, this is slow too.
        PaymentResult payment = paymentClient.charge(
                request.getCardToken(), request.getAmount());
        if (!payment.isSuccess()) {
            throw new PaymentFailedException("Payment declined");
        }

        // The client is left waiting for BOTH network calls to finish.
        return new OrderResult(request.getOrderId(), "CONFIRMED");
    }
}

Now the loosely coupled version using an event‑driven approach:

// Publish an event and return immediately. Downstream services react on their own.
public class OrderService {

    private final EventPublisher   eventPublisher;   // publishes to a broker (e.g. Kafka)
    private final OrderRepository  orderRepository;  // Order Service's OWN database

    public OrderService(EventPublisher eventPublisher, OrderRepository orderRepository) {
        this.eventPublisher  = eventPublisher;
        this.orderRepository = orderRepository;
    }

    public OrderResult placeOrder(OrderRequest request) {
        // Save order locally as PENDING - no network call to other services required.
        Order order = new Order(request.getOrderId(), request.getItemId(), "PENDING");
        orderRepository.save(order);

        // Publish an event; Inventory and Payment services react independently.
        eventPublisher.publish(new OrderCreatedEvent(order.getId(), request));

        // Respond immediately - the client does not wait for Inventory or Payment.
        return new OrderResult(order.getId(), "PENDING");
    }

    // Later, this method reacts asynchronously when Payment confirms success.
    public void onPaymentSucceeded(PaymentSucceededEvent event) {
        Order order = orderRepository.findById(event.getOrderId());
        order.markConfirmed();
        orderRepository.save(order);
    }
}

In a distributed monolith, data often has no single owner — and that is exactly why a schema change from one team routinely takes another team’s unrelated service down.

6.1 The lifecycle of a request in a distributed monolith

Trace the complete lifecycle, including all the places where things can go wrong, using our order‑placing example.

1. 1. Request arrives.

   Client sends an HTTP request to the API Gateway.

2. 2. Routing.

   Gateway decides which internal service handles it.

3. 3. First hop.

   Order Service starts processing and immediately needs data it does not own (stock level), so it must call out.

4. 4. Network serialisation.

   The request object must be converted to JSON, sent over the network, received, and deserialised by Inventory — a step that does not exist in a true monolith (an in‑process function call is instant, no serialisation needed).

5. 5. Nested calls.

   Inventory repeats the same serialisation dance with Warehouse.

6. 6. Latency accumulation.

   Every hop adds network latency (often 10–100 milliseconds each), so a request that would take 5 ms inside a true monolith might now take 300–800 ms.

7. 7. Failure propagation.

   If any hop times out, the failure must be caught and translated back up the chain, often losing context about the real root cause.

8. 8. Data write.

   The final result is written to the shared database, guarded by shared table locks that other services are also competing for.

9. 9. Response.

   The result travels back up through every hop to the client.

6.2 Data ownership lifecycle problem

In a distributed monolith, data often has no single owner. Multiple services read and write the same tables, so nobody can safely say “I know exactly how this data changes.” That creates a specific lifecycle problem:

1. 1. Team A adds a new column to the shared orders table.

   Feels harmless, is deployed on a Tuesday morning.

2. 2. Team B’s Reporting Service silently breaks because it selects *.

   The extra column doesn’t match its data model.

3. 3. On‑call engineer is paged at night.

   Errors are climbing on a dashboard that has nothing to do with Team A’s change.

4. 4. Root cause takes hours to find.

   Two unrelated teams have to be pulled in to diagnose one change.

6.3 Correct data lifecycle: database‑per‑service

In a properly decoupled system, each service is the single owner of its own data. If another service needs that data, it must ask through a well‑defined API or subscribe to events — never read the database directly.

A distributed monolith is not “evil” on purpose — it usually forms as a step along the way while a team is learning. Here’s what people think they’re gaining, versus what they actually lose.

7.1 Perceived advantages (why teams think they’re doing it right)

• Separate repositories per team — teams feel ownership over “their” codebase, at least visually.
• Separate deployment pipelines exist — there is at least a CI/CD pipeline per service, which is a step towards automation.
• Technically possible to scale services separately — even if it is rarely done safely because of tight coupling.
• Feels modern — matches the industry trend of moving away from “legacy monoliths.”

7.2 Real disadvantages

• All the complexity of distributed systems — network failures, serialisation, retries, timeouts — with none of the independence benefits.
• Slower than a true monolith — every network hop adds latency an in‑process function call never had.
• Harder to debug — a single user request now spans multiple services, multiple log files, and multiple servers, making root‑cause analysis much harder (this is exactly why distributed tracing exists — covered later).
• Coordinated deployments — teams still release multiple services together, defeating the entire purpose of “independent deployability.”
• Cascading failures — one slow or crashed service freezes a whole chain of dependent services (explained in Section 9).
• Higher infrastructure cost — more servers, more network calls, more monitoring tools, more operational overhead, for the same (or worse) functionality.
• False sense of security — teams believe they have “microservices” and stop worrying about coupling, when in fact the coupling is just as bad as before, only hidden behind network boundaries.

7.3 Trade‑off table: monolith vs. distributed monolith vs. true microservices

Splitting services does not automatically make anything faster — in a distributed monolith, it usually makes things slower and stops adding capacity where you need it.

8.1 Why performance suffers

Every network call has overhead that does not exist in a normal function call. Compare, in rough numbers, to build intuition:

In our earlier “Place Order” example, if Order → Inventory → Warehouse → Payment → Ledger each take even just 10 ms of pure network overhead (ignoring the actual work), that alone adds 40–50 ms of “wasted” time a true monolith would never have paid.

8.2 Scalability illusions

Teams often assume, “because it’s split into services, I can scale each service independently.” This is only true if the services are actually decoupled. In a distributed monolith, if Payment is the bottleneck but Order cannot proceed without Payment’s synchronous reply, then scaling Order alone does nothing — the chain is only as fast as its slowest link.

8.3 How to actually gain scalability

• Use asynchronous messaging so slow services do not block fast ones.
• Cache read‑heavy data locally inside the service that needs it, instead of calling another service on every request.
• Apply the Bulkhead pattern (Section 15) to isolate failures so one slow dependency cannot consume all your server’s threads or connections.
• Design for eventual consistency where the business allows it (e.g., “Order confirmed” now, “Payment settled” a few seconds later) instead of forcing everything to be perfectly synchronous.

8.4 Load balancing role

A load balancer distributes incoming requests across multiple copies (instances) of the same service, so no single server becomes overwhelmed.

In a distributed monolith, load balancing individual services provides limited benefit, because the entire request chain is still gated by the slowest, most tightly‑coupled dependency. Load balancing works best when services are truly independent, so scaling one link in the chain actually speeds up the whole system.

A cascading failure is one small failure in one service spreading and taking down other, otherwise‑healthy services — exactly the kind of outage a distributed monolith is prone to.

9.1 Cascading failures explained

What it is: a cascading failure happens when one small failure in one service spreads and causes failures in other, otherwise‑healthy services.
Why it happens in distributed monoliths: because services block and wait on each other synchronously, a slow or crashed service can make its callers pile up waiting requests, eventually running out of memory, threads, or connections themselves — causing them to fail too, even though their own code was perfectly fine.

9.2 Patterns that prevent cascading failures

Circuit Breaker Pattern

What it is: a circuit breaker watches calls to a dependency. If failures cross a threshold, it “opens” and stops sending new requests to that dependency for a while — failing fast instead of waiting and piling up.

public class CircuitBreaker {
    private int failureCount = 0;
    private final int failureThreshold = 5;
    private boolean open = false;
    private long openedAt;
    private final long resetTimeoutMillis = 30_000; // 30 seconds

    public boolean allowRequest() {
        if (open) {
            // After some time, allow a single "trial" request through.
            if (System.currentTimeMillis() - openedAt > resetTimeoutMillis) {
                open = false;
                failureCount = 0;
                return true; // trial request
            }
            return false; // circuit still open, fail fast
        }
        return true;
    }

    public void recordFailure() {
        failureCount++;
        if (failureCount >= failureThreshold) {
            open = true;
            openedAt = System.currentTimeMillis();
        }
    }

    public void recordSuccess() {
        failureCount = 0;
        open = false;
    }
}

Bulkhead Pattern

What it is: the bulkhead pattern isolates resources (like thread pools or connection pools) per dependency, so a problem in one dependency cannot consume the resources needed to talk to a different, healthy dependency.

Retry with Exponential Backoff

What it is: instead of retrying a failed call immediately (which can worsen an overloaded service), the caller waits progressively longer between retries (e.g., 1 s, 2 s, 4 s, 8 s).

Timeouts

What it is: a maximum time a service will wait for a reply before giving up. Without timeouts, a hanging dependency can freeze the caller forever.

9.3 Reliability in true microservices vs. distributed monoliths

When a monolith becomes distributed, requests that used to be safe in‑memory function calls now travel across a network — new endpoints, new credentials, new attack surface.

10.1 New security surface area

When a monolith becomes distributed, requests that used to be safe in‑memory function calls now travel across a network — sometimes across the public internet, or between data centres. This introduces new risks:

• More network endpoints to secure — every service‑to‑service call is a potential entry point for attackers if not authenticated.
• Credential sprawl — many services now need their own credentials (API keys, database passwords), multiplying the ways secrets can leak.
• Broader attack surface for shared databases — if five services all connect directly to one database, a leaked credential from the weakest service can expose everyone’s data.

10.2 Core security concepts explained

Service‑to‑Service Authentication (mTLS)

What it is: mutual TLS means both sides of a connection (not just the client, but also the server) prove their identity using certificates before any data is exchanged.

Zero‑Trust Networking

What it is: an approach where no service automatically trusts another service just because it is “inside the network.” Every request must prove its identity and permissions, every time.
Why it matters for distributed monoliths: in tightly coupled systems, teams often assume “it’s internal, so it’s safe,” skipping authentication between services entirely — dangerous, because if an attacker breaches any one service, they can freely call every other service.

Principle of Least Privilege for Shared Databases

What it is: each service should have only the exact database permissions it needs (e.g., read‑only on certain tables), not full access to everything.

10.3 Practical security checklist

• Authenticate every service‑to‑service call (mTLS or signed tokens like JWT).
• Give each service its own, narrowly‑scoped database credentials.
• Use an API Gateway to centralise authentication for external traffic, but do not let it become a single point of trust for internal traffic too.
• Rotate secrets and credentials regularly, and store them in a secrets manager, not in code or config files.
• Log and monitor cross‑service calls for unusual patterns (a service suddenly calling another it never called before could signal a breach).

In a true monolith, if something breaks, you look in one log file. In a distributed system, a single user request may touch 5, 10, or 20 services — without good tooling, root cause becomes a needle in a beach of sand.

11.1 Why observability becomes urgent

In a true monolith, if something breaks, you look in one log file. In a distributed system — monolith or not — a single user request may touch 5, 10, or 20 services. Without proper tooling, finding “what actually broke” becomes like finding one specific grain of sand on a beach.

11.2 The three pillars of observability

Logging

What it is: recorded text messages describing what happened inside a service (e.g., “Order 12345 created,” “Payment failed: card declined”).
Why it’s harder in distributed systems: logs are scattered across many different servers and services. A centralised logging system (the ELK stack — Elasticsearch, Logstash, Kibana — or cloud‑native tools like AWS CloudWatch Logs) is needed to search across all services at once.

Metrics

What it is: numeric measurements over time — like request count, error rate, average response time, CPU usage.

Common tools: Prometheus (collects and stores metrics), Grafana (visualises them in dashboards).

Distributed Tracing

What it is: a technique that tags a single request with a unique “trace ID” as it travels through every service, so the entire journey — every hop, every delay — can be seen in one connected view.

Common tools: Jaeger, Zipkin, and the OpenTelemetry standard (an open, vendor‑neutral way to collect traces, metrics, and logs).

11.3 Java example: adding a trace ID to logs

import org.slf4j.MDC;
import java.util.UUID;

public class TraceIdFilter {

    public void handleIncomingRequest(HttpRequestContext ctx) {
        String traceId = ctx.getHeader("X-Trace-Id");
        if (traceId == null) {
            traceId = UUID.randomUUID().toString();
        }
        // MDC (Mapped Diagnostic Context) attaches traceId to every log line
        // automatically for this request, across the whole call.
        MDC.put("traceId", traceId);

        // Pass the same traceId header when calling downstream services,
        // so all services can be joined together in tracing tools.
        ctx.addOutgoingHeader("X-Trace-Id", traceId);
    }
}

11.4 Alerting best practices

• Alert on symptoms the customer feels (error rate, latency) — not just internal server metrics that may not matter to users.
• Set up Service Level Objectives (SLOs) — a target like “99.9% of requests succeed within 300 ms” — and alert when at risk of missing them.
• Avoid alert fatigue: too many noisy alerts train engineers to ignore all of them, including the important ones.

If your deployment runbook says “deploy Payment first, wait for it to be healthy, then deploy Order, then restart Inventory” — you are looking directly at a distributed monolith. True microservices should be deployable in any order, any time, without coordination.

12.1 Deployment coupling: the biggest tell‑tale sign

If your deployment process requires a runbook such as “deploy Payment Service v2.3 first, wait for it to be healthy, then deploy Order Service v4.1, then restart the Inventory Service,” you are looking directly at a distributed monolith. True microservices should be deployable in any order, at any time, without coordination.

12.2 Containers and orchestration

What a container is: a lightweight, portable package that bundles application code together with everything it needs to run (libraries, settings), so it behaves the same on any machine.

What container orchestration is: a system (like Kubernetes) that automatically starts, stops, restarts, and scales many containers across many machines, based on rules you define.

12.3 Deployment strategies that reduce risk

12.4 Cloud‑native considerations

• Auto‑scaling: cloud platforms (AWS, Azure, Google Cloud) can automatically add or remove server instances based on load — but this only helps if the service being scaled is not blocked waiting on a tightly‑coupled dependency.
• Managed message queues: services like Amazon SQS/SNS, Google Pub/Sub, or Apache Kafka (self‑hosted or managed) make it easier to adopt asynchronous communication, directly helping break the “distributed monolith” chain of blocking calls.
• Service mesh: tools like Istio or Linkerd handle service‑to‑service traffic (retries, timeouts, mTLS, load balancing) outside of application code, which can help apply resilience patterns consistently, even in a system that is still partially coupled.

The single biggest lever for undoing a distributed monolith is giving each service its own database. Everything else — caching, load balancing, event flows — becomes easier once data ownership is clear.

13.1 Database‑per‑service pattern (the fix for shared databases)

What it is: each service gets its own database (or at minimum, its own schema or tables that no other service is allowed to touch directly).
Why it exists: it removes the hidden coupling point a shared database creates, letting each team change their own data model freely.

13.2 Handling data that used to be joined in one shared database

A common worry: “But I used to do a simple SQL JOIN between Orders and Customers — how do I do that now that they’re in separate databases?” Two common solutions:

• API Composition: call both services’ APIs and combine the results in application code (simple, but adds latency).
• Materialised View / Read Model: the Order Service subscribes to CustomerUpdated events from the Customer Service and keeps a small local copy of just the customer fields it needs (like name and email), so it never needs to call out at all for reads.

13.3 Caching

What it is: storing a copy of frequently‑needed data somewhere fast to access (like memory), so you do not need to repeatedly fetch it from a slower source (like a database or another service).

Common caching tools: Redis, Memcached.
Why it matters here: caching data that rarely changes (like product categories) locally inside a service can remove the need for many of the blocking, synchronous calls that create distributed‑monolith chains.

13.4 Load balancing recap in this context

Load balancers distribute traffic across multiple instances of the same service (explained with an analogy in Section 8). In the context of fixing a distributed monolith, load balancers work best paired with: (1) each service owning its own database, so scaling does not create write conflicts, and (2) asynchronous communication, so scaling one service does not require also instantly scaling everything downstream of it.

Good APIs are stable, coarse‑grained, and versioned. Bad APIs are chatty, brittle, and change constantly — the connective tissue that quietly turns services into a distributed monolith.

14.1 What makes an API “microservice‑friendly”

A good API contract between services should be:

• Stable: doesn’t change shape often; when it must change, it does so in a backward‑compatible way (adding new optional fields instead of removing old ones).
• Coarse‑grained: represents a meaningful business action (“place an order”), not a tiny technical detail (“update row 5 of table X”). Fine‑grained “chatty” APIs cause many small back‑and‑forth calls, which increases coupling and latency.
• Versioned: old clients using an older API version should keep working while new clients use the newer version.

14.2 REST vs. gRPC vs. Messaging — where each fits

14.3 The “chatty API” anti‑pattern

What it is: completing one business action requires many small, sequential API calls between two services (e.g., “get customer,” then “get customer address,” then “get customer preferences” — three separate round trips instead of one).

14.4 API Gateway’s role in a healthy microservices setup

What it is: a single entry point that all external client requests pass through, which then routes each request to the correct internal service.

An API Gateway is healthy when it only handles cross‑cutting technical concerns (authentication, rate limiting, routing) — it becomes part of the “distributed monolith” problem if business logic starts leaking into it, because then it becomes yet another tightly‑coupled dependency every request must pass through.

Every anti‑pattern that turns services into a distributed monolith has a matching design pattern that undoes it — Domain‑Driven Design, Saga, Strangler Fig, and the Anti‑Corruption Layer are the essentials.

15.1 Anti‑patterns that create distributed monoliths

Anti‑pattern: Splitting by technical layer, not business capability

Creating a “Validation Service,” a “Formatting Service,” and a “Database Access Service” as separate deployables means nearly every single business action needs to call all three in sequence. Instead, split by business capability: “Order Service,” “Payment Service,” “Shipping Service” — each handling its own validation, formatting, and data access internally.

Anti‑pattern: Shared mutable library for business logic

If five services all import the same shared library containing core business rules, and that library changes, all five services must be recompiled and redeployed together — recreating the “single deployable unit” problem the split was supposed to remove.

Anti‑pattern: Synchronous call chains for non‑critical steps

Making the customer wait for an email confirmation service to respond before confirming their order is unnecessary — sending the email can safely happen asynchronously, after the order is already confirmed.

Anti‑pattern: The “Distributed Monolith Database”

As discussed extensively in Sections 6 and 13 — multiple services directly reading and writing one shared database.

15.2 Design patterns that fix these anti‑patterns

Domain‑Driven Design (DDD) — Bounded Contexts

What it is: a method for figuring out where one service’s responsibility ends and another begins, by grouping related business concepts (a “bounded context”) together.

Saga Pattern

What it is: a way to manage a business transaction that spans multiple services, without requiring one giant locked database transaction. Each step publishes an event; if a later step fails, earlier steps run “compensating actions” to undo their work.

Strangler Fig Pattern

What it is: a gradual migration strategy where new functionality is built as separate services around the edges of an old monolith, slowly “strangling” it, until the old monolith can be fully retired — instead of a risky, all‑at‑once rewrite.

Anti‑Corruption Layer

What it is: a thin translation layer placed between a new service and an old, messy monolith (or another poorly‑designed service), so the new service’s clean design does not get “corrupted” by old assumptions.

15.3 Quick‑reference: anti‑pattern to pattern mapping

Eight habits that keep a microservices system from silently becoming a distributed monolith — and five mistakes that guarantee it will.

Companies that avoided the distributed monolith — and companies that publicly discussed discovering they had built one, then how they climbed out.

Ten questions across beginner, intermediate, and advanced difficulty — the kind of distributed‑monolith questions that come up in nearly every senior system‑design interview.

The questions people ask most about distributed monoliths, and the ideas worth carrying with you long after you close this tab.

Frequently Asked Questions

At its heart, the distributed‑monolith story is not about a specific technology — it is about the difference between splitting code and splitting responsibility. Move code across repositories without moving ownership, and the coupling simply hides behind a network cable. Move ownership carefully — of data, of deployment, of failure — and each service can genuinely grow, fail, and recover on its own. The systems that stay calm under real‑world stress are almost always the ones whose engineers took that second step seriously, and refused to be fooled by architecture diagrams that looked microservice‑shaped but behaved like one giant, brittle stone.