Microservices promise independent deployment, focused ownership, and failure isolation. Yet many systems split a codebase into dozens of services without gaining those properties. A single user request crosses six network boundaries, every deployment requires coordinated testing, and one slow dependency degrades the entire platform.
The result is a distributed monolith: monolithic coupling combined with distributed-system failure modes.
The problem is not that services communicate. It is that too many business operations require a synchronous chain of services to be available, responsive, and behaviorally compatible at the same moment. Reducing that runtime coupling requires more than adding retries or a message broker. It requires changing service boundaries, data ownership, workflows, and failure expectations.
How synchronous dependencies recreate monolithic coupling
Consider an order endpoint that calls customer, inventory, pricing, payment, and notification services before responding:
flowchart LR
Client --> Gateway
Gateway --> Orders
Orders --> Customers
Orders --> Pricing
Orders --> Inventory
Orders --> Payments
Orders --> Notifications
The services may live in separate repositories and deploy through separate pipelines, but the order operation still behaves as one large runtime unit. Its success depends on every required service and network path completing within the request deadline.
This creates several forms of coupling:
- Availability coupling: A dependency outage prevents the caller from completing its work.
- Latency coupling: A slow downstream call consumes the caller's latency budget and resources.
- Capacity coupling: A traffic spike propagates through the call graph, potentially overloading services that were not sized for it.
- Change coupling: Contract or semantic changes require coordinated releases across teams.
- Temporal coupling: All participants must be available at the same time.
Even when each dependency is highly available, a long request path has more opportunities to fail. Multiplying availability percentages can illustrate the risk for independent failures, although real failures are often correlated through shared infrastructure, deployment mistakes, or traffic patterns. The more important operational fact is simple: the endpoint's reliability cannot exceed that of every mandatory dependency on its critical path.
Recognizing a distributed monolith
Repository count is not a useful architecture metric. Look instead at runtime and delivery behavior.
Operational warning signs
Common symptoms include:
- A minor service outage breaks unrelated customer journeys.
- One request produces a deep or branching chain of synchronous calls.
- Retry storms amplify load during an incident.
- Thread pools, connection pools, or event loops saturate while waiting for downstream responses.
- Teams cannot deploy safely without a coordinated release window.
- Integration environments must contain nearly every service to test one feature.
- Services frequently query one another for data needed on every request.
- A shared database or shared schema allows changes to bypass service contracts.
- Incidents are diagnosed by manually tracing calls across many dashboards.
A service graph is especially revealing. Identify the longest synchronous paths, high fan-out nodes, and services with many inbound callers. Those are usually better refactoring targets than the services with the most code.
The chatty request path
Fine-grained service boundaries can make ordinary operations unexpectedly expensive. A product page might request product details, then synchronously fetch price, availability, promotions, reviews, and seller status. If each service makes more calls, the total fan-out grows quickly.
Parallel calls can reduce nominal latency, but they do not remove runtime coupling. The response still depends on all mandatory calls, while concurrency may increase instantaneous load. Parallelism is useful only after deciding which data is actually required, which can be stale, and which can be omitted under degradation.
How cascading failure develops
A typical cascade begins with a slow dependency rather than a clean outage:
sequenceDiagram
participant C as Client
participant O as Order service
participant I as Inventory service
participant D as Database
C->>O: Create order
O->>I: Reserve stock
I->>D: Query stock
D-->>I: Slow response
I-->>O: Timeout
O->>I: Retry
I->>D: Query stock again
C->>O: Client retry
O->>I: More requests
As requests wait, the caller retains memory, connections, worker capacity, and queue slots. Retries add traffic precisely when the dependency has the least spare capacity. Upstream timeouts can cause clients to retry while the original work continues, creating duplicate operations. Eventually, a local slowdown becomes system-wide resource exhaustion.
Three implementation mistakes make this worse:
- Missing or inconsistent deadlines. A downstream timeout longer than the upstream deadline permits useless work after the caller has given up.
- Unbounded retries. Multiple layers retry independently, multiplying attempts across the call chain.
- No admission control. The system accepts more work than it can complete, turning overload into long queues and timeouts.
Contain failure before redesigning workflows
Resilience controls do not eliminate coupling, but they can stop one dependency from consuming the whole system while deeper changes are underway.
Propagate deadlines and cancel abandoned work
Start each request with an end-to-end deadline. Every downstream call must receive a smaller budget that leaves time for the caller to process the result and return a response.
function callInventory(request, requestDeadline):
remaining = requestDeadline - now()
if remaining < 100 milliseconds:
return deadlineExceeded
callBudget = min(remaining - 50 milliseconds, 500 milliseconds)
return inventory.reserve(request, timeout=callBudget)
The exact values must come from the operation's latency objective and observed behavior; they should not be copied blindly. Cancellation should propagate when supported so that abandoned database queries and network calls stop consuming capacity.
Retry selectively and within a budget
Retry only failures that are plausibly transient, such as a connection reset or an explicit temporary-unavailable response. Do not retry validation failures or deterministic authorization denials.
Use exponential backoff, jitter, and a strict attempt or time budget. Prefer retrying at one responsible layer rather than at every hop. Write operations also require idempotency. An idempotency key lets a service recognize a repeated request and return the original outcome instead of charging a card or creating an order twice.
Retries trade a possible recovery for additional load and latency. Under sustained overload, failing fast is usually safer.
Add circuit breakers and bulkheads
A circuit breaker temporarily rejects calls after a dependency crosses a failure threshold. This limits waiting and gives the dependency an opportunity to recover. A half-open state can allow a small number of probes before normal traffic resumes.
Bulkheads isolate resource pools by dependency or workload. For example, payment calls should not share every worker and connection with optional recommendation calls. Concurrency limits are often more valuable than large queues because they bound active work and expose overload quickly.
These controls need careful tuning. A circuit breaker configured too aggressively can create self-inflicted outages, while one global breaker may hide differences between endpoints or regions. Bulkheads also reserve capacity that may sit unused. Their purpose is predictable isolation, not maximum utilization.
Design explicit degraded responses
Not every dependency deserves to be on the critical path. If reviews are unavailable, a product page may still render. If a recommendation service times out, the endpoint can omit recommendations rather than fail the purchase flow.
Fallbacks must be semantically safe. Serving a cached product description is different from guessing a payment authorization or inventory reservation. Classify dependencies as:
- Required: The operation cannot be correct without the result.
- Degradable: A stale, partial, or omitted result is acceptable.
- Deferred: The work can happen after the response.
This classification makes graceful degradation a product decision rather than an improvised incident response.
Reduce runtime coupling with architectural patterns
Once immediate cascades are contained, remove dependencies from critical request paths.
Publish events for work that does not require an immediate answer
Notification, analytics, search indexing, and many downstream projections usually do not need to complete before a command returns. The owning service can commit its state and publish an event for asynchronous consumers.
A reliable implementation commonly uses a transactional outbox:
BEGIN;
INSERT INTO orders (id, customer_id, status)
VALUES (:order_id, :customer_id, 'PENDING');
INSERT INTO outbox (event_id, event_type, aggregate_id, payload)
VALUES (:event_id, 'OrderCreated', :order_id, :payload);
COMMIT;
A separate relay publishes committed outbox rows to a broker. Because the order and outbox record share a local transaction, the system avoids the gap where the database commit succeeds but direct event publication fails.
This does not provide magical exactly-once processing. Relays can publish duplicates, so consumers should be idempotent, often by recording processed event identifiers alongside their local changes. Teams must also handle delayed delivery, ordering boundaries, dead-letter handling, schema evolution, and replay.
Build local read models
A service that synchronously calls another service on every request just to retrieve reference data has not achieved runtime independence. Instead, it can subscribe to domain events and maintain a local projection containing the fields it needs.
For example, the order service might store a local view of customer eligibility rather than call the customer service during every checkout. The customer service remains the source of truth, while the order service owns its task-specific projection.
This introduces eventual consistency and duplicated data. The tradeoff is often worthwhile for availability and latency, but only when the business can tolerate a defined staleness window. Sensitive or rapidly changing decisions may still require synchronous validation. Make that choice explicitly rather than applying local caches to every dependency.
Model long-running operations as sagas
Some workflows genuinely span multiple owners. Creating an order may require inventory reservation and payment authorization, but a distributed transaction across all services is usually undesirable or unavailable. A saga models the workflow as a sequence of local transactions with compensating actions.
flowchart LR
A[Create pending order] --> B[Reserve inventory]
B --> C[Authorize payment]
C --> D[Confirm order]
B -. failure .-> E[Reject order]
C -. failure .-> F[Release inventory]
F --> E
Compensation is business logic, not database rollback. Releasing inventory can undo a reservation, but sending a follow-up refund does not erase the fact that a payment was captured. States such as PENDING, CONFIRMED, REJECTED, and REFUND_REQUIRED make this reality visible.
Sagas can be orchestrated by a workflow component or choreographed through events. Orchestration centralizes workflow visibility and timeout handling but can become an overly powerful coordinator. Choreography reduces central control but becomes difficult to understand when many services react indirectly. Prefer explicit orchestration for complex, business-critical workflows and keep the orchestrator focused on process state rather than domain rules owned by participants.
Revisit service boundaries
Resilience mechanisms cannot repair boundaries that split a single invariant across multiple services. If two services must communicate synchronously for nearly every operation, deploy together, and change together, they may belong in one service.
Merging services is not architectural failure. A well-structured modular monolith can provide clearer ownership and stronger local transactions than prematurely distributed components. Extract a service when there is a meaningful ownership, scaling, security, lifecycle, or availability boundary—not merely a noun in the domain model.
A practical migration sequence
A distributed monolith rarely needs a rewrite. Refactor the highest-risk paths incrementally:
- Map critical request graphs. Use distributed traces and service-level metrics to identify fan-out, tail latency, retry volume, and common failure paths.
- Define operation budgets. Set end-to-end deadlines, propagate cancellation, and align downstream timeouts.
- Bound resource use. Add concurrency limits, small bounded queues, bulkheads, and load shedding.
- Remove optional calls. Defer notifications and analytics; degrade optional response sections.
- Replace repeated lookups. Build event-fed local projections where bounded staleness is acceptable.
- Make workflows explicit. Introduce idempotency, durable state transitions, and saga compensation for multi-service operations.
- Correct the boundaries. Merge services with inseparable invariants or redesign APIs around cohesive business capabilities.
- Test failure behavior. Exercise timeouts, duplicate messages, unavailable dependencies, slow databases, and partial workflow completion.
Measure progress with customer-facing outcomes: fewer dependencies on critical paths, lower tail latency, reduced retry amplification, smaller failure domains, and the ability to deploy a service without coordinating unrelated teams.
Conclusion
A microservice architecture becomes a distributed monolith when service separation exists mainly at deployment time while business operations remain tightly joined at runtime. Synchronous APIs are sometimes necessary, but every mandatory call spends latency, availability, and capacity budgets.
First contain cascades with deadlines, bounded retries, idempotency, circuit breakers, bulkheads, and load shedding. Then remove temporal coupling through asynchronous events, transactional outboxes, local read models, and explicit sagas. Finally, reconsider boundaries that force constant coordination.
The goal is not to eliminate communication. It is to ensure that services can fail, recover, scale, and evolve without requiring the entire system to move with them.
