Manage queues, acknowledgements, and retries | Middleware: understand and operate the chain

Accepting a message is not business completion

Publisher confirmation and consumer acknowledgement serve different purposes. In RabbitMQ, the broker may confirm acceptance to the publisher before a consumer finishes work. To claim business completion, define functional evidence such as a processing record or reconciliation. Do not confuse “sent,” “accepted,” and “applied.”

Redelivery and idempotency

If a consumer applies an operation and fails before acknowledgement, the message may be delivered again. An idempotent operation tolerates repetition without incorrectly repeating its effect. This may require a business key and a transactional processing record. “The message has an ID” is insufficient unless the consumer uses it to control duplication. Consider ordering and partial-failure behavior too.

Depth, age, and controlled recovery

A large queue can be normal during a peak; oldest-message age and ingress/egress rates help assess delay. If egress is below ingress, backlog grows. Distinguish missing consumers, slow consumers, and repeatedly failing messages. An error queue needs triage, a corrected cause, and controlled replay. Replaying everything without deduplication can worsen the incident.

Workplace application

In a fictional financial-instruction consumer, separate broker acceptance, consumer delivery, and recorded effect. If the process fails after the effect but before ack, recovery can redeliver the message. Use business identity and the idempotency contract to decide. Observe ready, unacked, age, and rates; an empty ready queue does not prove no work remains in flight.

IN PRACTICE

A consumer recorded a payment instruction and failed before acknowledgement. The message reappears during recovery. The team must consult the business key and application evidence before repeating the effect; queue presence does not prove it was never processed.

Common pitfalls

Confusing confirm with business completion; replaying without effect control.

Related topics: Release, observe, and recover middleware · Retries, idempotency, and limits

Take this idea with you

Delivery and application are different events; safe recovery considers repetition and reconciliation.

Create account

Reference: Consumer acknowledgements and publisher confirms · DR Middleware 2026.4; HotSpot JDK 25; JDBC 25; PostgreSQL 18; RabbitMQ 4.3; OpenSSL 3.5; explicitly scoped runtime references