Using publisher confirms with RabbitMQ, in which cases publisher will be notified about success/failure?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
When working with RabbitMQ, ensuring the reliability of message delivery is crucial for building robust applications. One powerful feature provided by RabbitMQ to guarantee messages have been safely received by the broker is Publisher Confirms. This article explores the concept of publisher confirms, how it is implemented, technical scenarios of its usage, and the circumstances under which a publisher will be notified about success or failure.
Understanding Publisher Confirms
Publisher confirms are a RabbitMQ feature that allows clients to be sure that their messages have been received by the broker. This is particularly useful in scenarios where message delivery assurance is critical, such as financial transactions, order processing systems, or any use-case where data integrity is paramount.
In its essence, the feature extends the Advanced Message Queuing Protocol (AMQP) by adding an acknowledgment mechanism from the broker to the publisher. Messages can be published in either a transactional or confirm mode, though confirms are generally preferred due to better performance.
How Do Publisher Confirms Work?
When publisher confirms are enabled, each time a message is published to the exchange, the broker sends back an acknowledgment (ack) or a negative-acknowledgment (nack) to the publisher. This response lets the publisher know whether the message was successfully routed and saved to queues or if it needs to be resent.
Steps to Implement Publisher Confirms:
- Enable confirms on a channel. This can be done using
channel.confirmSelect()if you are using a client library that supports it. - Publish messages as usual.
- Handle the acknowledgments sent by the broker.
When Will Publishers Be Notified?
| Event | Description |
| Message is queued | Publisher receives an 'ack' when the message is successfully queued. |
| Failure in message routing | If no queue is bound to the exchange, the message is unroutable and results in a 'nack'. |
| Broker failure | In cases of broker errors or failures, a 'nack' can also be sent, depending on the severity and settings. |
| Network issues | Network failures might delay or prevent delivery of 'ack' or 'nack'. Persistent messages may still recover. |
Technical Example
Consider a scenario using Python with Pika, a RabbitMQ client library.
Best Practices and Considerations
- Performance Impact: Enabling publisher confirms introduces a round-trip delay per message, as the broker needs to communicate back to the publisher. Batch confirmations can mitigate this.
- Error Handling: Implement robust error handling to manage 'nack' responses and potential exceptions.
- Monitoring: Keep an eye on the message acknowledgments and failure rates to proactively manage potential issues in message delivery.
Using publisher confirms in RabbitMQ effectively enhances the reliability of message delivery. By understanding and handling the success or failure notifications from the broker, developers can build more resilient and fault-tolerant systems.

