Diseñando jobs en segundo plano idempotentes: reintentos, locks y la ilusión del exactly-once

Todos los sistemas de colas que vas a usar —SQS, RabbitMQ, BullMQ, Sidekiq, Pub/Sub— prometen entrega "at-least-once" (al menos una vez). Ninguno promete exactly-once, porque la entrega exactly-once en un sistema distribuido es demostrablemente imposible sin la cooperación del consumidor. La red puede perder un ack. Un worker puede caerse después de hacer el trabajo pero antes de confirmarlo. Un reintento puede disparase mientras el intento original todavía está corriendo.

La verdad incómoda: la garantía de entrega de tu cola no es tu problema. El comportamiento de tu handler de jobs ante ejecución duplicada, sí lo es. Si diseñas asumiendo "esto va a correr más de una vez, a veces de forma concurrente", el comportamiento exactly-once se vuelve alcanzable aunque la entrega exactly-once nunca lo sea.