← Middleware: understand and operate the chain
11 / 12 · 50 MIN

Messaging: delivery and controlled recovery

Interpret confirmations, redelivery, and retention to recover messages without losing identity or effects.

Publish, route, and complete

In an AMQP 0-9-1 integration, separate broker acceptance, routing, and business completion. In a RabbitMQ 4.3 example, the application publishes with mandatory and receives a no-route return followed by publisher ack. Confirmation does not turn an unrouted message into a processed instruction. Preserve identifiers and the return reason; inspect exchange, bindings, and the key used. Only then define controlled repetition and acceptance criteria. The operating report should show known state at each boundary, including outstanding consumer outcomes, so business does not receive a success claim unsupported by evidence.

Tags, channels, and out-of-order completion

Delivery tags belong to the channel where delivery occurred. When distributing work across threads, preserve delivery-to-channel association and respect the library’s concurrency model. An acknowledgement on another channel can produce unknown delivery tag and close that channel. Also inspect multiple: acknowledging through tag 12 can include still-outstanding 10 and 11. In an exercise, 12 completes first while 10 is still writing. Use individual acknowledgement or track an actually completed work boundary. The broker does not automatically know handler transaction state or repair premature acknowledgement.

Prefetch and consumer shutdown

Prefetch limits outstanding deliveries within its configured scope. With three consumers capped individually at twenty and no other ceiling, up to sixty deliveries can remain unacknowledged. This is permitted capacity rather than proof of useful activity. Relate it to memory, handler duration, and dependency capacity. During shutdown, cancelling the subscription stops future new deliveries but neither completes nor automatically requeues earlier ones. Count in-flight work and define completion or controlled recovery before closing the channel. Always confirm behavior for the client library and version in use.

Retries and counters in the correct version

An invalid message can consume resources by cycling rapidly without progress. In RabbitMQ 4.3 quorum queues, basic.nack used to return the message does not increment delivery-count like basic.reject; do not assume delivery-limit stops that loop. Define a retry budget, appropriate delay, and a retention path for unprocessable items. In an exercise, useful queue work slows after migration because the team retained an older counter assumption. Identify effective semantics and protect the flow before changing rejection behavior. Rejecting without requeue or a suitable destination can replace amplification with loss.

Dead-lettering and source pressure

Dead-lettering is another transfer that can fail. A configured DLX alone does not establish safe retention while the destination is unavailable. For quorum queues’ at-least-once mode, validate requirements together, including compatible strategy and overflow. While confirmations are missing, the source retains messages and consumes resources; monitor limits and destination availability. Under pressure, switching to drop-head is not a neutral adjustment: it can delete still-unconfirmed items. The decision needs population, impact, and authorization. Retain duplicate handling because retried transfer does not guarantee unique application effects.

Recover topology, identity, and outcomes

A recovered connection does not mean the integration can already resume. Confirm channels and required topology before subscriptions and respect what the library recovers automatically. Then reconcile publishes without confirms and deliveries with unknown outcomes. Preserving a business ID helps recognize repetition but requires application idempotency handling and persisted state; the field does not implement that logic alone. In an exercise, a publisher repeats after losing its confirm. The consumer should recognize the already-applied result and avoid duplicating the effect while retaining evidence and batch-closure criteria.

IN PRACTICE

A mandatory publish receives basic.return and then ack. The ack does not remove routing failure: preserve the operation and inspect topology before repeating.

Common pitfalls

Confirm as business completion; global tags; nack as a universal counter; configured DLX as guaranteed retention.

Related topics: Operate TLS, certificates, and configuration · Manage queues, acknowledgements, and retries · Release, observe, and recover middleware

Take this idea with you

Define each confirmation’s scope and verify retention, identity, and state before recovery.

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