Using RabbitMQ Publisher Confirms for Reliable Message Publishing

The problem: messages disappearing before they’re safe

When a publisher sends a message to RabbitMQ, the call returns immediately. If the broker crashes before persisting the message, the publisher has no way to know the send failed, leading to silent loss.

Why publisher confirms help

Publisher confirms is a channel‑level flag that makes the broker send a Confirm OK frame after it has persisted the message (or stored it in a queue). The publisher can then treat the send as acknowledged only after receiving that frame.

Enabling confirms

You can turn the feature on globally in rabbitmq.conf or per‑connection/channel. Example using rabbitmqctl to set the policy for a vhost:

# Enable publisher confirms for all connections in vhost /myapp
rabbitmqctl set_policy --apply-to connections publisher_confirms "^" '{"publisher-confirms":true}' -p /myapp

Or, if you prefer the config file, add:

publisher_confirms = true

After changing the setting, restart the node or reload the configuration (rabbitmqctl reload_vhost_variables) for the change to take effect.

Working example with a client library

The following pseudo‑code shows how a publisher using the AMQP 0‑9‑1 client (e.g., Pika for Python) can wait for confirms:

import pika
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
# Enable confirms on this channel
channel.confirm_delivery()

try:
    # Publish a message; the method returns False if the broker cannot
    # assign a confirmation number immediately (rare) or True otherwise.
    if channel.basic_publish(
        exchange='',
        routing_key='orders',
        body='{"order_id":123}',
        properties=pika.BasicProperties(delivery_mode=2)
    ):
        # Wait for the broker's Confirm OK
        method_frame = channel.wait_for_confirms()
        if method_frame.method.NAME == 'Basic.Ack':
            print('Message persisted')
        else:
            print('Message not persisted')
    else:
        print('Unable to publish (no confirmation slot)')
except Exception as e:
    print(f'Error: {e}')
finally:
    connection.close()

If the broker crashes before persisting the message, the wait_for_confirms call will timeout or raise an exception, giving the publisher a chance to retry or log the failure.

Trade‑offs and limitations

• Confirms only guarantee that the broker has written the message to disk (or replicated it, depending on the queue type). They do not guarantee that a consumer has processed it.
• Enabling confirms adds a small round‑trip overhead; publishers that need to send tens of thousands of messages per second should benchmark with rabbitmq-stress to measure latency impact.
• Confirm OK frames are not persisted across broker restarts. If the broker crashes after persisting a message but before sending the Confirm OK, the publisher will treat the message as unconfirmed and may safely retry, potentially causing duplicates—hence the need for idempotent consumers.

How to verify that confirms are working

1. Check the setting: rabbitmqctl confirm_status -p /myapp should show true for the connection or channel.
2. Enable debug logging in your client library (most have a flag to log Confirm OK and Confirm Nack frames).
3. Publish a test message and stop the broker immediately after the basic_publish call. The publisher should not receive a Confirm OK and can detect the loss.

Actionable next steps

Start by enabling publisher confirms on a staging vhost, run a representative load test, and monitor the latency introduced. If the overhead is acceptable, roll the change out to production and add retry logic that treats a missing confirm as a transient failure. Combine confirms with idempotent consumer handling to achieve a practical at‑least‑once delivery guarantee.