For failed messages in Azure Service Bus and AWS SQS, a periodic health-record cleanup should not depend on a web request staying open; choose retry logic from the delivery guarantee the job needs. For a cleanup that can be repeated safely, I would use a durable queue, a bounded visibility or lock interval, explicit attempt state, and a dead-letter path. The important comparison is not which queue has the nicer retry API. It is what happens after a worker disappears between the database commit and the acknowledgement.

That boundary decides the design.

I would model a cleanup item with an idempotency key such as patient_id + cleanup_period , then make the database write conditional on that key. That gives the scheduler permission to redeliver work without turning a transient timeout into duplicate deletion.…