27.8 Sync vs async calls between services: when to use which?

In the restaurant: For your main course, you wait at the counter: you can't eat without it. For the "your loyalty card has a new stamp" note, you don't wait; the stall does it after you've left.

In the system:

• Synchronous (HTTP, gRPC): the caller waits for the answer. Use it when the caller needs the result now: "is this book in stock?", "did the payment go through?". The caller's availability now depends on the callee's.
• Asynchronous (queues, events, Chapters 22 and 23): the caller sends and moves on. Use it when the work can happen a moment later: confirmation emails, loyalty points, search indexing, analytics.

In the chapter's code, if the email service is down, a synchronous checkout fails the order; with the email sent asynchronously through a queue, the order is placed and the email waits.

Rules of thumb:

• Keep synchronous chains short (ideally one or two hops from the user request). Long chains multiply latency and failure (27.5).
• Every synchronous call needs a timeout and a plan for failure (Chapter 29). The Level 4 bug is what happens without one.
• Prefer events for "something happened" so new consumers don't require changes to the publisher.
• Don't fake sync over async (send a message, then block waiting for a reply) unless you really need it.

Memory code: "Wait at the counter only for what you're about to eat."

---