Sync waits on the same connection. Async hands off and moves on.
Synchronous gets an answer now and ties you to the callee. Asynchronous gets an ack in milliseconds; the work, and any reply, come later.
7 hours
of failures a month, ten 99.9% services
A synchronous chain works only if every link is up, so 0.999¹⁰ ≈ 99.0%. Nobody chose a 99% service; you get one by adding calls.
1,000 requests/s at 80 ms: 80 in flight. Then a dependency hangs until a 2 s timeout.
The trick
2,000 in flight. 200 threads finish 100 a second; 900 queue or fail.
A queue soaks up the spike; workers drain it later.
5,000 orders a second for 10 minutes; invoice workers handle 1,000. The backlog drains in about 80 minutes. No checkout fails.
Does async make the work faster?
Bad: Async is faster
Move the work onto a queue and it gets done sooner.
Good: Only the response is
End to end it’s slower: broker hop, queue wait, polling.
A short synchronous spine; every side effect is an event.
Pricing, payment and one write with an outbox row take 170 ms on three components, not 490 ms on seven. Restaurant, rider and SMS react later.
Decide per interaction, not once per system
- Need the result for the next step? Synchronous.
- Fine if the consumer is down 10 minutes? Async.
- Takes more than a few seconds? 202 plus a status.
Remember
Keep the user’s critical path synchronous and short, with deadlines and idempotency keys. Push every side effect onto events, written through an outbox.