Dead-letter queue: qué es y cómo usarla

Una dead-letter queue (DLQ), o cola de mensajes fallidos, es un destino separado para mensajes que no pudieron procesarse después de los intentos permitidos. En vez de bloquear indefinidamente la cola principal, el sistema aparta esos mensajes para inspeccionarlos y decidir si se corrigen, se reintentan o se descartan. AWS y Azure documentan este patrón para sus servicios de mensajería.

También puede servirte: Qué es un rate limit en una API y cómo aplicarlo

La DLQ no arregla el error por sí sola. Conserva el mensaje y su contexto para que el equipo pueda encontrar la causa: datos inválidos, una dependencia caída, un cambio de contrato o un límite alcanzado. En algunos servicios, el mensaje conserva propiedades de entrega y la razón del descarte, pero el formato exacto depende de la plataforma.

Una cola de fallos es útil cuando un mensaje problemático no debería impedir que continúen los demás. El límite de reintentos evita gastar recursos en un caso que seguirá fallando y permite que la cola principal mantenga su ritmo. Google Cloud explica un mecanismo equivalente con dead-letter topics para mensajes que no fueron confirmados tras varios intentos.

El umbral debe reflejar el tipo de error. Un timeout transitorio puede merecer algunos reintentos con espera, mientras que un esquema inválido necesita corrección o rechazo. Si todos los mensajes terminan en la DLQ, el problema está en el consumidor, las credenciales o el contrato; moverlos de vuelta sin diagnóstico sólo repite la falla.

Definí qué información se guarda: identificador, fecha, cantidad de entregas, error observado y versión del consumidor. Separá mensajes que pueden reprocesarse de los que necesitan una corrección manual. La política de retención debe ser suficiente para investigar, pero no tan larga como para ocultar un problema de producción.

Creá un flujo de revisión con permisos limitados. Antes de reinyectar, validá el payload y probalo con la misma versión que falló. Registrá cada movimiento para saber cuántos mensajes volvieron a la cola, cuántos se descartaron y por qué. Una métrica de profundidad de DLQ y una alerta por antigüedad suelen ser más útiles que contar sólo errores de la aplicación.

Una DLQ no debería ser un depósito permanente ni un reemplazo de observabilidad. Si los mensajes contienen información sensible, aplicá el mismo control de acceso y cifrado que en la cola principal. También revisá el orden: algunas plataformas pueden romper el orden original al mover o reinyectar mensajes, y el comportamiento cambia según el servicio.

Documentá qué ocurre cuando la DLQ llega a su capacidad o vence la retención. La decisión puede ser reintentar, corregir y reinyectar, enviar a un flujo manual o eliminar con evidencia. El patrón funciona cuando hace visible el fallo y protege el flujo normal, no cuando oculta errores detrás de una segunda cola.