What are the trade-offs between synchronous and asynchronous communication?

Question

Accepted Answer

**Synchronous** communication blocks the caller until a response arrives; **asynchronous** communication sends a message and continues without waiting. Each makes different trade-offs in coupling, latency, and resilience.

## Comparison

| Aspect | Synchronous (REST/gRPC) | Asynchronous (messaging) |
|---|---|---|
| Caller waits? | Yes | No |
| Temporal coupling | Tight | Loose |
| Resilience to outages | Low | High (broker buffers) |
| Consistency | Immediate | Eventual |
| Complexity | Lower | Higher |
| Debuggability | Easier (linear) | Harder (flows) |

## Visual

```text
SYNC:  Caller ──request──▶ Service
       Caller ◀─response── Service   (blocked the whole time)

ASYNC: Caller ──message──▶ [ Queue ] ──▶ Service
       Caller continues immediately; Service handles it later
```

## Rule of thumb

- Use **sync** when the user needs an answer now (e.g., load a profile).
- Use **async** for background work, fan-out, and to survive downstream outages (e.g., send a confirmation email).

## Pitfall

Async hides failures — a dropped or poison message can silently break a workflow. You need dead-letter queues and monitoring.

## Why it matters

The choice directly controls how failures propagate: sync calls fail fast and visibly, async messages decouple but defer problems to consumers.

Mixing them well — sync at the edge, async for workflows — is a core skill in building resilient microservices.

Caller waits?	Yes	No
Temporal coupling	Tight	Loose
Resilience to outages	Low	High (broker buffers)
Consistency	Immediate	Eventual
Complexity	Lower	Higher
Debuggability	Easier (linear)	Harder (flows)