🏗️ Architecture

Sync vs Async Communication

When to call directly (HTTP/gRPC) vs go through a broker.

Synchronous (HTTP/gRPC): caller blocks (or awaits) for an immediate response — simple to reason about and debug, but couples the caller to the callee's availability right now; if the callee is down or slow, the caller feels it immediately (and it can cascade under load — the classic distributed-systems failure mode).

Asynchronous (message broker — NServiceBus/RabbitMQ/Azure Service Bus): caller publishes/sends and moves on; the message sits in a queue until a consumer is ready. Decouples availability (the consumer can be down and catch up later) and time (consumer doesn't have to process instantly) at the cost of not having an immediate answer — you need to either not need one (fire-and-forget-ish Commands/Events) or handle the response asynchronously too (e.g. a follow-up event, polling, or a callback).

Rule of thumb for choosing: does the caller need the result right now to continue (sync), or is this "make sure this eventually happens, and I don't need to wait" (async)? A checkout flow showing order confirmation needs a fast sync response; sending the order-confirmation email is a perfect async event handler — nobody should wait on SMTP to see their confirmation page.

Flashcards (2)

What's the main risk of synchronous service-to-service calls under load, beyond just 'it's slower'?

tap to reveal answer

Cascading failure — if a downstream service is slow/down, callers block waiting on it, which can exhaust the caller's own thread pool/connections and take it down too, propagating the failure upstream through the call chain.

Give the rule of thumb for choosing synchronous vs asynchronous communication for a given interaction.

tap to reveal answer

Does the caller need the result right now to proceed (sync/HTTP), or does the caller just need to ensure something eventually happens without waiting on it (async/message)? E.g. showing an order confirmation = sync; sending the confirmation email = async event.