Communication Styles: Sync vs Async

Style before technology

Newman’s thesis: teams pick a technology (REST, gRPC, Kafka) before deciding what style of communication they need. Set technology aside and build a vocabulary. Moving from in-process to inter-process calls, three things change: performance (network calls can’t be inlined; payload and serialization now matter), changing interfaces (provider and consumers deploy separately, so backward-incompatible changes force lockstep or phased rollouts), and error handling (new failure modes — crash, omission, timing, response, and arbitrary/Byzantine failures; HTTP status codes model rich semantics, e.g. a retryable 503 vs a pointless-to-retry 404).

The model of styles

graph TD
Start{"What do you need?"}
Start -->|"a reply / something done"| RR["Request-response"]
Start -->|"emit a fact, don't care who acts"| EV["Event-driven"]
RR --> SB["Synchronous blocking<br/>(keep connection open)"]
RR --> AB["Asynchronous nonblocking<br/>(via queue/broker)"]
EV --> ASYNC["Nonblocking asynchronous only"]

First choose request-response vs event-driven; if request-response, choose synchronous vs asynchronous; event-driven is limited to nonblocking asynchronous. Mix and match is the norm.

A poison message shows why async needs a safety valve — without a retry cap a single bad message can take down the whole pool:

graph LR
Q["Queue"] --> W["Worker"]
W -->|"crash, requeue"| Q
W -->|"retries exceed limit"| DLQ["Dead letter queue<br/>(message hospital)"]
DLQ --> H["Human / automated triage"]

• Synchronous blocking — simple and familiar, but creates temporal coupling, susceptibility to slow downstreams, and cascading failures in long call chains (MusicCorp’s fraud example). Remedies: restructure interactions (move fraud detection off the critical path) or go nonblocking.
• Asynchronous nonblocking — temporal decoupling, good for long-running work (a warehouse dispatch taking hours or days), at the cost of complexity and choice. (Note: await is still blocking from the code’s perspective.)
• Communication through common data — one service writes to a known location (file, store) that others later consume (data lakes for loose coupling, warehouses for tighter). Simple, ubiquitous, great for large volumes and interoperability — but usually high-latency (polling).

Request-response: a “request” beats a “command”

For fetching data or ensuring something is done, prefer a request (examinable, rejectable) over a command. Synchronous keeps a connection open; asynchronous routes via a queue/broker (buffering benefits, but you must correlate and route the response). All forms need time-out handling.

Event-driven: emit facts, don’t issue orders

A service emits events — factual statements that something happened — without knowing who consumes them, greatly reducing coupling. An event is a fact (the payload); a message is the medium. Implement via message brokers (“keep the middleware dumb, the smarts in the endpoints”).

What’s in an event?

• Just an ID — causes a barrage of callbacks and re-adds coupling.
• Fully detailed events — Newman’s preference: self-sufficient consumers and a historical record useful for event sourcing. But watch event size, PII leakage, and the fact that event data becomes part of your contract.

See also

• Choreography vs orchestration — who drives a multi-service process.
• Sagas — coordinating state changes without distributed transactions.
• Resilience — timeouts, retries, and circuit breakers for synchronous calls.

When to use it — and when not

Related topics