Short answer: inspect the dead-letter queue, choose a bounded batch of failed jobs, and redrive those messages to the main queue. A worker then retries the cleanup with an idempotency key. The important design choice is the recovery boundary: the scheduler starts work, the queue holds it, and the worker owns the retry-safe operation.

For a logistics system, that boundary matters. A periodic cleanup may remove expired shipment holds or reconcile stale delivery records. Keeping an HTTP request open for the whole job makes recovery harder. A queue gives the work a durable place to wait, while a DLQ gives operators a place to inspect failures instead of silently losing them.

Which retry option fits your recovery model?

Option Pick this when Main trade-off

RabbitMQ DLX You already operate RabbitMQ and want dead-letter routing close to the broker You own the broker topology and the redrive procedure

Amazon SQS DLQ redrive Your queues live in AWS and the operational workflow should stay in AWS The workflow is…