Part 5 · 1 chapters · ~8 min
Synchronous versus Asynchronous Integration
Availability and latency of synchronous chains, temporal coupling, what the user must wait for, request-reply over queues, async with status resources, timeouts and fallbacks at each hop, and a decision table.
8
Sync chains multiply failure
| question | sync (HTTP/gRPC) | async (queue/event) |
|---|---|---|
| does the caller need the answer now? | yes: authorisation, balance check | no: receipt, analytics, search indexing |
| if the callee is down… | the caller fails or degrades | work waits in the queue |
| load spikes | propagate instantly | absorbed by the queue |
| debugging | one trace | trace context through messages, harder |
| consistency | read-your-writes possible | eventual; design the pending state |
code
p = 0.999 ** 5 # 0.995 → 0.5% of requests fail if any hop fails independently # hedges: timeouts per hop that fit the overall budget, fallbacks (cached data), circuit breakers (Mesh P1)
AVAILABILITY OF A SYNCHRONOUS CHAIN
each service 99.9% available; the request needs all of them
swipe the figure sideways, or tap expand for full screen
1/4
multiply
If a request synchronously needs N services each 99.9% available, the request is available about 0.999^N of the time.
availability multiplies0.999^N