Publisher Confirms vs Transactions: Throughput vs Duplicate Handling

Answer first

Publisher Confirms give much higher throughput than AMQP Transactions and both are at-least-once. Neither mechanism prevents duplicates, and consumer crash behavior is independent of how the message was published.

Your three questions

• Consumer crash after ack but before a transaction commit. Confirmed: a consumer basic.ack removes the delivery from RabbitMQ immediately on the broker side. A publisher-side transaction commit does not affect that delivery. If the consumer crashes after the broker received the ack, the message is lost from the queue and will not be redelivered. If the consumer crashes before the ack is sent, RabbitMQ will requeue the message and it can be redelivered to another consumer. This requeue behavior is the same regardless of whether the publisher used confirms or transactions.
• Broker configuration that guarantees no duplicates from transactions under a crash. Confirmed: no broker configuration guarantees exactly-once delivery or eliminates duplicates for publisher transactions. Transactions only guarantee that a batch of publishes is atomically accepted or rejected by the broker. Duplicate risk comes from the producer side retrying after a network partition or timeout, not from the broker. Consumer-side duplicates are controlled by ack/nack timing, not by publisher transactions.
• Duplicate risk: confirms vs transactions at high throughput. Confirmed: both mechanisms provide at-least-once semantics. Publisher Confirms allow asynchronous, batched acknowledgments and therefore sustain significantly higher messages-per-second per channel than synchronous transactions. Transactions require a full round-trip commit per batch, which severely limits throughput. The risk of duplicates under both is similar in principle: if the producer does not receive the commit/confirm due to a network or process failure, a retry can cause the broker to store the same message again. In practice, confirms expose a larger window for retries under high throughput because more messages are in flight, while transactions reduce in-flight messages at the cost of throughput.

Confirmed facts from RabbitMQ behavior

• Publisher Confirms are asynchronous and batchable; AMQP Transactions are synchronous and block the channel until commit/rollback.
• Neither Confirms nor Transactions provide end-to-end exactly-once delivery. They only ensure the broker has accepted responsibility for a message.
• Consumer crashes are independent of the publishing protocol. Un-acked messages are requeued; acked messages are removed.
• Duplicate handling must be implemented at the consumer application level, e.g., idempotent processing and deduplication keys.

Likely explanation vs uncertainty

Likely explanation for the confusion in the prompt: a consumer ack and a publisher transaction commit operate on different channels and different protocol flows. There is no RabbitMQ consumer transaction commit that can undo a basic.ack. The scenario "consumer crashes after acknowledging a message but before a transaction commit" mixes publisher and consumer concerns.

Uncertainty to flag for review: the exact duplicate delivery behavior when a consumer crashes during a transaction is not fully documented in the provided brief, and broker settings such as publisher_confirms, delivery_mode, and queue durability influence durability but not duplicate semantics. Testing is limited to a single node with the default guest account, so remote-connection and network partition duplicate scenarios are excluded.

Steps needed for this case

1. Measure throughput locally: compare messages per second with channel.txSelect() and commit vs channel.confirmSelect() with batched confirms on the same single-node setup.
2. Verify consumer requeueing: publish with either mechanism, start a consumer that does not ack, kill the consumer process, and observe redelivery.
3. Verify ack loss: have a consumer ack then crash before persisting work, and confirm the message is not redelivered.

One missing diagnostic detail that changes the recommendation: are you referring to publisher transactions on the producer channel, or do you intend a transactional consumer channel where acks are also wrapped in a transaction? Clarifying this separates publisher durability from consumer acknowledgment semantics and determines whether the test should focus on txCommit timing or on basic.ack timing.