Asynchronous Communication

Work Can Be Handed Off Without Waiting for Completion

With asynchronous communication, the sender hands off a message or event and continues working without requiring the receiver to return an immediate result in the same call.

Service A -> message broker -> Service B
    |
    +-> continues

For example, after an order is created, the main request can finish, while sending an email, updating analytics, and other background actions are performed separately.

Services Depend Less on Each Other in Time

The receiver can temporarily run slower or be unavailable while messages remain in an intermediate layer for some time. This helps absorb short load spikes and prevents the sender from waiting for every background operation.

But the result is no longer immediate. There is a delay between sending a message and actually changing another part of the system, so a user or another service may sometimes observe state that has not been updated yet.

Asynchrony Requires Explicit State Management

If the result of background work must be known, it cannot simply be returned as the return value of the current call. The system has to store status, correlate messages with identifiers, or receive a separate completion event.

In addition, the same message can arrive more than once, and processing order does not always match send order. Later in this section we will separately examine delivery patterns and how to handle duplicates safely.