¿Cómo diseñas un consumidor para una cola que garantiza entrega al menos una vez?

Da por hecho que cada mensaje puede llegar más de una vez y haz que el procesamiento sea idempotente. Deriva una clave estable del mensaje y, o bien la compruebas y la registras en un almacén antes de actuar, o usas una escritura condicional para que una repetición no haga nada. Fija el visibility timeout por encima de tu peor caso de tiempo de procesamiento, extiéndelo para trabajos largos, y manda los mensajes a una dead letter queue tras unos pocos fallos para que los mensajes envenenados no bloqueen el avance.

Parto del supuesto de que todo mensaje llegará al menos dos veces en algún momento, normalmente porque un consumidor iba lento y el visibility timeout expiró cuando el trabajo ya estaba confirmado. Así que el consumidor tiene que ser idempotente, y quiero que eso sea concreto y no aspiracional. Normalmente es una clave de idempotencia sacada del mensaje, o un id que puso el productor o un hash del contenido significativo, registrada en una tabla con una restricción de unicidad dentro de la misma transacción que el trabajo. Si el insert entra en conflicto, esto ya lo hicimos, confirma y sigue. Cuando el efecto es una escritura en un almacén prefiero una actualización condicional, así aplicarla dos veces deja el mismo estado. En lo operativo, el visibility timeout tiene que superar el tiempo de procesamiento realista más lento, y para trabajos genuinamente largos extiendo el arrendamiento sobre la marcha en vez de fijar un timeout global enorme. Los fallos reintentan con backoff exponencial y jitter, y tras un número pequeño de intentos el mensaje va a una dead letter queue con el error adjunto, así un mensaje malo nunca bloquea al resto.