When Service A calls Service B, which calls Service C, all over blocking synchronous HTTP, what is 'temporal coupling', and how does it turn a single slow dependency into a wider outage?

## What a blocking call actually does A blocking synchronous call works like this: the caller opens a connection, sends a request, and holds a thread or worker slot idle until a response arrives before it can continue. Chained across three services, A calling B calling C, A's handler thread is occupied for the entire duration of B's call, which is itself occupied for the entire duration of C's call. This means: - the **response time** of A can never be faster than the response time of B, which can never be faster than the response time of C; - and critically, the **availability** of A depends on the availability of B which depends on the availability of C. If each hop is independently 99.9% available, three hops in series with no fallback compound to roughly 99.7% — worse than any single hop, not equal to the best one. ## Why the shape survives the split This pattern exists because synchronous request/response is the most natural mental model for engineers coming from a monolith, where a module boundary was just an in-process function call. When a team extracts a module into its own service, the easiest change is to replace the in-process call with an HTTP or gRPC call to the new service and leave everything else about the interaction untouched — same caller, same wait-for-response semantics, same position in the call graph. That's precisely the **distributed-monolith signature**: the topology of a tightly coupled call graph didn't change, only its transport did, from an in-process stack frame to a network hop. ## What each style buys and costs Synchronous calls buy real benefits, and the cost is real too. | Style | What it buys | What it costs | |---|---|---| | **Synchronous calls** | They're simple to write and reason about, and they give strong consistency, since the caller knows the downstream operation completed (or explicitly failed) before proceeding. | Temporal coupling itself, plus thread and connection exhaustion under partial failure, plus amplified end-to-end latency, since latencies on the critical path sum across hops. | | **Asynchronous messaging** — queues, event streams | Removes temporal coupling because producer and consumer no longer need to be up at the same instant. | It costs you immediate consistency and adds real operational complexity: brokers, retries, ordering guarantees, poison messages, and a harder debugging story across an async boundary. | ## The failure shape in production In production this shows up as a recognizable failure shape often called a **retry storm**: C gets slow, B's calls to C start timing out, B's own clients (including A) retry, multiplying load on an already-struggling C. Worse, if B has a limited thread or connection pool shared across all its downstream calls, threads blocked waiting on slow C leave nothing available to serve requests that have nothing to do with C, so B goes fully unresponsive rather than just degraded for the C-dependent path. Mitigations like these all reduce blast radius: - **circuit breakers**, which trip to fail fast instead of piling up waiting threads - **bulkheads**, which isolate a separate thread pool per downstream dependency so a stuck C can't starve B's other call paths - **timeouts**, which bound how long any thread waits But they don't remove the underlying temporal coupling. B is still unable to serve anything requiring C while C is down; it just fails fast and predictably instead of hanging and cascading. ## Where the fix actually lies This exact problem is why Netflix built Hystrix: in their early microservices architecture, a single slow dependency several hops deep could exhaust request-handling threads across the whole call graph and take down the API gateway, even though the failing service was minor and non-critical. That experience pushed Netflix toward circuit breakers, bulkheading, and, for many interactions, asynchronous event-driven communication instead of synchronous chains. The remediation direction for a distributed monolith exhibiting this pattern is to separate calls into two buckets: - those on the critical, user-facing path that genuinely need an immediate response, kept synchronous but wrapped in timeouts, circuit breakers, and bulkheads; - those that were only made synchronous because that was the path of least resistance during extraction, which should be converted to asynchronous messaging so producer and consumer are decoupled in time, not merely decoupled in deployment.