Indirect messaging lets microservices announce events without calling one another. A sender publishes through an intermediary, and a receiver handles the message later. Neither endpoint needs to know which other microservice is involved; the sender may not even know whether anyone will receive it. section 5.6.2
To put the pattern to work with RabbitMQ:
- Add a RabbitMQ server. Senders and receivers locate it through DNS rather than locating each other. section 5.8.2
- Use amqplib to publish to a named queue or exchange, then receive messages from a queue. A receiver can pull messages when it is ready. section 5.8.2
- Choose a single-recipient message or a broadcast that can notify multiple recipients. section 5.8.9
A video-viewed event
A video-streaming microservice publishes a “Viewed” message through RabbitMQ. A history microservice picks it up to record viewing history. Other microservices can later respond to the same event without changing the sender. section 5.8 section 10.7.5
Use indirect messaging when the sender does not need an immediate success or failure response, particularly for application-wide event notifications. Use direct HTTP messaging when a named recipient must reply or one operation must finish before the next begins. Indirect messaging reduces coupling, but its communication paths can become harder to trace. RabbitMQ is not immune to failure; if a consumer crashes before acknowledging a message, another consumer can eventually handle it. section 5.9 section 5.8.8
Figure 5.6 An indirect message isn’t explicitly sent to a microservice; instead, the message is placed in a queue and can be handled later.
The diagram shows the intermediary that separates the sender from the receiver and allows the message to be handled later. section 5.6.2
