Dead Letter Queue
Qué es
Una Dead Letter Queue (DLQ) es un destino para mensajes que no pueden continuar por el flujo normal bajo una política definida. Los separa para inspección, reparación, replay o resolución explícita, conservando información que permita entender el fallo.
El nombre puede representar una cola, subcola o destino equivalente. Los criterios y garantías dependen del sistema de mensajería. Enterprise Integration Patterns presenta Dead Letter Channel como el destino de mensajes que el sistema determina que no puede o no debe entregar. Dead Letter Channel.
DLQ no significa éxito ni recuperación automática. El pedido que necesitaba reservar inventario sigue sin esa reserva. Mover su mensaje cambia quién debe resolver el problema; no completa la intención original.
Qué problema resuelve
Un mensaje problemático puede fallar repetidamente, ocupar workers y demorar trabajo que sí podría avanzar. Separarlo permite continuar según la política del negocio y conservar evidencia para operar el fallo.
El beneficio exige un responsable. Una DLQ sin alertas, inspección o tratamiento de mensajes antiguos solo oculta trabajo incompleto. Una retry queue mantiene la intención de volver a intentar automáticamente; retry-topologies muestra esa diferencia y la transición cuando la política se agota. Tampoco es una respuesta suficiente a una caída general de una dependencia: miles de mensajes correctos pueden terminar allí y seguir necesitando procesamiento.
Qué mensajes pueden llegar
- Poison messages: provocan fallos repetibles por sus datos o por un defecto del handler.
- Errores de schema o validación: versión no soportada, estructura inválida o información necesaria ausente.
- Fallos repetidos: errores transitorios o de operación que agotan la política de retry. Es un criterio frecuente, no un requisito para todo traslado a DLQ.
- Mensajes expirados: cuando el transporte y su configuración destinan allí trabajo fuera de su plazo.
- Problemas de entrega: rutas, permisos o destinos incompatibles, según la implementación.
No todo rechazo de negocio es un poison message. «No hay stock» puede ser un resultado válido que el flujo debe comunicar, no un error técnico que se repita hasta agotar intentos. La política debe distinguir esas situaciones.
El agotamiento de intentos tampoco prueba que el payload sea incorrecto. Una dependencia puede seguir indisponible o el consumidor puede perder acknowledgements. Azure Service Bus documenta tanto límites de entrega como expiración y rechazo explícito; son ejemplos de políticas concretas, no reglas universales de DLQ. Service Bus Dead-Letter Queues.
Mecanismo y frontera de transferencia
La DLQ debe conservar la identidad de aplicación, origen, motivo, versión del contrato, correlación y evidencia suficiente para decidir qué pasó. Registrar «error» sin contexto dificulta distinguir payload inválido, resultado incierto y servicio caído. El diagnóstico debe evitar copiar secretos o datos sensibles innecesarios.
El traslado también puede fallar. Si una aplicación publica en otro destino y después reconoce el original, vuelve a existir una frontera entre escrituras: reconocer primero puede perderlo; publicar primero y caer puede duplicarlo. Hay que conocer la operación atómica o el mecanismo de transferencia durable que realmente ofrece el transporte.
RabbitMQ documenta que ciertos modos de dead-lettering pueden perder mensajes si el destino no está disponible, y distingue otros modos con confirmaciones. No basta con haber configurado un nombre de DLQ para demostrar conservación. Dead Letter Exchanges: Safety.
Ejemplo: inventario no procesado
Inventory Consumer recibe evt-42-created, publicado desde transactional-outbox, pero su versión de schema todavía no está soportada. Tras clasificar el error, el mensaje se mueve a la DLQ con un motivo preciso. Order Service puede tener el pedido confirmado mientras la reserva aún falta.
El equipo identifica la incompatibilidad, despliega el handler compatible y revisa si existió algún efecto parcial. Después redrivea un lote pequeño y verifica reservas, errores y progreso. La cantidad de mensajes que salió de la DLQ mide transferencia; el éxito se comprueba en la frontera del procesamiento requerido.
Si el pedido ya fue cancelado, procesar ahora un evento viejo de creación puede ser incorrecto. Hay que consultar las reglas actuales, versiones y estados del dominio, y decidir si corresponde procesarlo, compensarlo o cerrar la intención por otra vía.
Remediation, replay y redrive
Una recuperación controlada necesita:
- Identificar la causa y qué efectos pudieron ocurrir.
- Corregir código, configuración o contrato antes de repetir.
- Seleccionar mensajes todavía válidos para esa recuperación.
- Reintroducirlos con una velocidad que consumidores y dependencias puedan sostener.
- Comprobar el efecto y conservar evidencia de los casos no resueltos.
Repetir la misma intención conserva su identidad de aplicación para que idempotent-consumer o inbox-pattern reconozcan efectos existentes. Si una reparación cambia la intención, necesita identidad y relación causal explícitas; no debe disfrazarse de copia idéntica.
Los IDs del transporte pueden cambiar durante redrive. SQS, por ejemplo, asigna nuevos IDs y tiempos de entrada y puede intercalar mensajes recuperados con publicaciones nuevas. Por eso no conviene basar la identidad de negocio ni el orden histórico exclusivamente en esos valores. SQS: DLQ redrive.
Riesgos operacionales y de seguridad
El redrive masivo puede provocar overload, reproducir el mismo fallo o generar un ciclo entre flujo normal y DLQ. deduplication limita repeticiones dentro de su contrato, no impide todos esos ciclos. Apartar un mensaje también puede romper un orden requerido: procesar el siguiente no siempre es válido si dependía del anterior.
Observar entradas por motivo, crecimiento, edad del mensaje pendiente más antiguo y casos resueltos. Una cola vacía puede significar procesamiento correcto, borrado administrativo o vencimiento: no son resultados equivalentes.
Retención y cleanup deben preservar tiempo de diagnóstico y límites de privacidad, evitando pérdida silenciosa al vencer o borrar. Algunos productos requieren limpieza explícita; otros tienen plazos de retención. Documentar cuál aplica y qué ocurre con las intenciones no resueltas antes de eliminar evidencia.
La DLQ puede acumular payloads personales, tokens enviados por error y detalles internos de excepciones. Restringir lectura y redrive, proteger datos almacenados y auditar cambios reduce exposición y acciones no autorizadas. Inspeccionar no requiere exportar indiscriminadamente todo el payload a logs o tickets.
Cuándo usarla y límites
Usarla para separar casos que necesitan otro tratamiento y permitir progreso donde el negocio admite esa separación. No usarla como sustituto de retries, idempotency, validación de contratos u observabilidad. at-least-once puede cubrir entregas repetidas mientras el destino de negocio permanece incumplido.
Si una secuencia exige continuidad estricta, aislar un mensaje puede requerir detener también su secuencia, no continuar todo por defecto. reliable-messaging permite revisar quién publica, quién procesa y quién recupera cada fallo. Una DLQ útil mantiene esa responsabilidad visible hasta que el negocio acepta su resolución.