Synchronous request-response and its limits

Use a synchronous call only when the result is needed right now, the complete required path fits inside a bounded deadline, and you can state a truthful outcome even when the wait fails. Everything else — work that can finish later, dependencies that are merely helpful, or an effect that cannot be resolved safely after a timeout — belongs on an asynchronous or accepted/pending path instead.

A synchronous call means the caller's path inherits the callee's latency, availability, and capacity constraints for the entire wait. This is not a detail to manage away — it is the defining cost of the pattern. Treat a request path as a budget, not a set of independent calls: the ingress deadline is divided among local work, downstream calls, network overhead, and a margin for building the response. A downstream call may spend only its assigned share of what remains.

• Dependency depth — each additional required, sequential call adds another chance that the whole path is slow or unavailable. End-to-end availability is bounded by the composition of every required dependency, not just the least reliable one.
• Fan-out and join — calling several dependencies in parallel lowers median latency versus calling them one after another, but a join that requires all of them still waits for the slowest required branch, and fan-out raises downstream load per request.
• Tail latency — a dependency that is usually fast but occasionally slow can dominate the percentile a user actually experiences. At a required join, the slowest branch decides completion, no matter how fast the others were.
• Cancellation — telling downstream work to stop when its result is no longer useful is best-effort. It is not evidence the work did not happen.
• Saturation — connections, worker slots, and database sessions are finite. A slow call holds them longer, which queues more work behind it and makes the next call slower too — a feedback loop, not an isolated delay.

A timeout is not the same thing as a deadline. A deadline is the end-to-end latest useful completion time for the whole operation; a timeout is a local limit on one particular wait, and it must fit inside whatever remains of that deadline. Independent, generously-set per-hop timeouts can add up to far more than the caller's actual budget, leaving downstream work running long after the client that asked for it has already given up and moved on.

A timeout does not mean the operation failed. It means the caller stopped waiting. The callee may have completed the work, may still complete it, or may never have received the request at all — "I did not receive success" is not evidence that "the action did not happen." Any side-effecting call that can time out needs a way to resolve that ambiguity afterward — an idempotency key, a durable status the caller can check — rather than a guess.

A synchronous call is the right tool when several of these hold:

• The result is genuinely required to make the immediate, user-visible decision — not merely convenient to have sooner.
• Interactive validation or an authorization/policy check must complete before an irreversible next step proceeds.
• The read is small and freshness truly matters for that specific decision, rather than being a default habit.
• A bounded command needs a definitive accept/reject answer the caller can act on immediately.
• The dependency has a clear owner, a known SLO, a bounded payload, and defined response semantics for both success and failure.

Every synchronous dependency a service adds is coupling it imports into its own request path, not just a function call:

• Inherited availability. The caller can only be as available as the composition of every dependency it synchronously requires.
• Inherited tail latency. A caller's p99 tracks whichever required dependency has the worst tail, even if that dependency is fast on average.
• Deployment and schema coordination. A breaking change on either side of a synchronous contract needs coordinated rollout, not independent release cadence.
• Held capacity. Connections, worker threads, and database sessions stay occupied for the whole wait, which is exactly the resource a burst of slow requests exhausts first.
• Retry amplification. If the client, a gateway, and the service itself each retry independently, one user request can become many downstream attempts precisely when the dependency has the least spare capacity.
• Cross-team on-call exposure. A synchronous call makes another team's incident your incident, the moment their dependency is on your critical path.

Move a step off the synchronous path when:

• The work can genuinely take seconds or minutes — document generation, provisioning, exports, settlement.
• The only dependency is an external provider with unpredictable latency, and the user does not need that provider's final answer before continuing.
• The result is nonessential enrichment — recommendations, analytics, notifications — rather than something the immediate decision depends on.
• The action is side-effecting and a timeout cannot be resolved safely through idempotency or a durable status lookup.
• Expected bursts would exhaust connection pools, worker slots, or downstream quotas while requests sit waiting.

The usual alternatives — an accepted/pending response backed by asynchronous processing, a queue handoff, client polling of a status resource, or a webhook notification — all share one property this article assumes rather than re-explains: work is durably recorded before the request returns, using the queue and outbox patterns already covered. What differs here is only the contract the caller sees: an immediate, truthful "accepted," not a final result.

A payment platform lets merchants request a payout of their available balance. The merchant dashboard needs an immediate answer about whether the *request* was accepted; actual payout execution goes through a bank-facing provider and can take minutes or hours. POST /payouts has a 1.5-second end-to-end target.

Flow:

1. The client sends POST /payouts with an idempotency key. The API derives an ingress deadline from the 1.5-second budget, reserving a fixed margin to serialize and return the response.
2. It checks for an existing idempotency record first. If one exists, it returns the durable prior result rather than starting new work — a double-click or client retry must not reserve funds twice.
3. It calls ledger reservation — checking account status and reserving the requested amount — with a 250 ms child budget, well inside the remaining deadline and with no independent timeout reset at that boundary. This call is required: the payout cannot be accepted without a real reservation.
4. In parallel, it starts an optional risk-explanation lookup, owned by another team, with a short 100–150 ms cancellable budget. This call is not required — it only supplies dashboard context.

1. If the ledger reservation succeeds, the handler writes the payout as accepted and an outbox intent to trigger downstream bank submission — in one local transaction, using the transactional-outbox pattern already covered rather than re-explained here. The API never calls the bank provider from the request path: bank submission can take seconds to hours and is not required for the caller's immediate decision.
2. The response means exactly one thing: the ledger reservation and payout intent are durably recorded. It does not mean money has reached the bank account. A separate status endpoint later reports accepted, submitting, submitted, or failed as the asynchronous worker advances the payout.

Classifying failure on the ledger call matters as much as the happy path. A retryable failure — a transport error or a 5xx before any durable acceptance — can be retried once, with a small bounded delay, only if enough of the remaining deadline is left to fit both the retry and the response margin. A permanent failure — the ledger definitively rejects, insufficient funds — returns a final, stable rejection immediately; retrying it wastes the budget on an answer that will not change. An outcome-unknown failure — the ledger call times out and the API cannot tell whether the reservation actually committed — must not be blindly retried as if it were a fresh attempt: the API resolves it through the idempotency record or a status lookup, the same way the payout worker resolves an ambiguous bank submission later, never by guessing that "no response" means "nothing happened."

That single retryable ledger attempt still needs backoff and jitter, at a much smaller scale than a background worker's: backoff is the delay itself — even one bounded retry should not fire immediately back-to-back with the failed attempt, in case the failure was a brief saturation spike — and jitter randomizes that delay so that many concurrent payout requests hitting the same transient ledger blip do not all retry in the same instant and recreate the spike they were reacting to. On a 250ms child budget there is only room for a tiny fixed-plus-jitter delay, not the multi-second exponential backoff a relay or background worker could afford — the distinction is the same, the numbers are just much smaller because the whole retry has to fit inside a deadline measured in milliseconds, not minutes.

Before adding or keeping a synchronous call on a request path, confirm:

• The result is actually required for the immediate decision, not merely convenient to have now.
• An end-to-end deadline is propagated from the top of the call chain, and each per-hop timeout fits inside what remains of it.
• Retryable, permanent, and outcome-unknown failures are classified separately, with retries bounded by the remaining deadline.
• Every side-effecting call that can time out has an idempotency key or a durable status the caller can resolve against.
• Optional dependencies are parallelized with a short, cancellable budget and degrade truthfully rather than blocking the response.
• Fan-out to required dependencies is bounded and explicit, not open-ended.
• The response contract distinguishes accepted from completed wherever the two are not the same moment.
• Connection, worker, and session limits are sized for the worst case this call's wait can create under saturation.
• The dependency has a named owner, a known SLO, and an explicit fallback when it is unavailable.