Colas de mensajes muertos (DLQ) en AWS: Qué son y cómo evitar perder datos en tus sistemas distribuidos
Este artículo está dirigido a desarrolladores que están aprendiendo AWS y quieren entender cómo construir sistemas distribuidos más robustos. Explicaremos desde cero qué es una DLQ (Dead Letter Queue, cola de mensajes muertos), por qué es esencial cuando trabajas con colas de mensajes, y cómo configurarla correctamente en Amazon SQS (Simple Queue Service, servicio de colas simples). Verás el concepto de Redrive Policy (política de reenvío), cómo monitorear la DLQ con Amazon CloudWatch.
El problema: ¿Qué pasa cuando un mensaje falla?
1.1. El rol de las colas en sistemas distribuidos
En una arquitectura de microservicios, los componentes no siempre se comunican directamente. Muchas veces un servicio productor (por ejemplo, el que recibe un pedido) envía un mensaje a una cola, y un servicio consumidor (por ejemplo, el que procesa el pago) lo lee y lo procesa cuando puede.
La cola actúa como un buffer (amortiguador): desacopla al productor del consumidor. Si el consumidor está lento o caído, los mensajes esperan en la cola en lugar de perderse.
Amazon SQS (Simple Queue Service, servicio de colas simples) es el servicio de colas administrado de AWS. No necesitas gestionar servidores; solo creas una cola y empiezas a enviar y recibir mensajes.
1.2 El mensaje envenenado (Poison Message)
Ahora imagina que un mensaje tiene un formato inválido, o que el código del consumidor tiene un bug que hace que falle al procesarlo. El consumidor recibe el mensaje, falla, y no lo borra de la cola. SQS, al no recibir confirmación de borrado, vuelve a hacer visible el mensaje para que otro consumidor (o el mismo) lo intente de nuevo.
Esto se repite indefinidamente. El mensaje se convierte en un poison message (mensaje envenenado): un mensaje que nunca se podrá procesar con éxito, pero que sigue consumiendo recursos de cómputo y, en el peor caso, bloquea el procesamiento de otros mensajes.
1.3 La solución: una cola para los mensajes problemáticos
Aquí entra la DLQ (Dead Letter Queue, cola de mensajes muertos). Es simplemente otra cola, separada de la cola principal, a la que SQS mueve automáticamente los mensajes que han fallado demasiadas veces.
La idea es: no dejes que un mensaje defectuoso bloquee el flujo normal. Sácalo de la cola principal y guárdalo aparte para que puedas investigarlo después sin prisa.
Servicios de AWS que usaremos
2.1 Amazon SQS (Simple Queue Service)
Qué es: el servicio de colas de mensajes administrado de AWS. Permite enviar, almacenar y recibir mensajes entre componentes de una aplicación de forma asíncrona.
Tipos de cola:
- Standard Queue (cola estándar): ofrece throughput (rendimiento) muy alto y at-least-once delivery (entrega al menos una vez). Un mensaje puede entregarse más de una vez, y el orden no está garantizado.
- FIFO Queue (cola FIFO, First-In-First-Out): garantiza que los mensajes se procesen exactamente en el orden en que se enviaron, y exactly-once processing (procesamiento exactamente una vez). Su rendimiento es menor que el de las colas estándar.
Regla importante: una cola FIFO solo puede tener como DLQ otra cola FIFO. Una cola estándar solo puede tener como DLQ otra cola estándar .
2.2 Amazon CloudWatch
Qué es: el servicio de monitoreo y observabilidad de AWS. Recopila métricas, logs y eventos de tus servicios.
Uso en este artículo: usaremos CloudWatch para crear una alarma (alarm) que se dispare cuando haya mensajes en la DLQ. La métrica clave es
ApproximateNumberOfMessagesVisible (número aproximado de mensajes visibles), que indica cuántos mensajes hay disponibles para ser consumidos en la cola .2.3 Amazon SNS (Simple Notification Service)
Qué es: el servicio de notificaciones pub/sub (publicación/suscripción) de AWS. Permite enviar notificaciones a múltiples destinos (correo, SMS, webhooks, etc.) desde un solo punto.
Uso en este artículo: lo mencionaremos como destino de las alarmas de CloudWatch, para que el equipo reciba una notificación cuando llegue un mensaje a la DLQ.
Los conceptos clave: Redrive Policy y maxReceiveCount
3.1 ¿Cómo decide SQS mover un mensaje a la DLQ?
SQS no mueve un mensaje a la DLQ al primer fallo. Sería demasiado agresivo: a veces un fallo es transitorio (un timeout de red, una base de datos momentáneamente lenta) y un reintento lo resuelve.
Para controlar esto se usa la Redrive Policy (política de reenvío). Es un atributo de la cola de origen (source queue) que le dice a SQS:
"Si un mensaje se ha entregado a un consumidor más de N veces y nunca se ha borrado, muévelo a esta DLQ."
El parámetro clave es
maxReceiveCount (número máximo de recepciones). Es el número de veces que un mensaje puede ser recibido de la cola de origen antes de ser movido a la DLQ .Ejemplo: si configuras
maxReceiveCount en 3, un mensaje que se reciba 3 veces sin ser borrado será movido a la DLQ en el cuarto intento.3.2 ¿Qué valor poner en maxReceiveCount?
No hay una respuesta única, pero aquí tienes una guía:
- Valor bajo (1-2): el mensaje va a la DLQ rápidamente. Útil si quieres detectar problemas pronto, pero puede generar falsos positivos por fallos transitorios.
- Valor alto (5-10): das margen para reintentos. Es lo recomendado en la mayoría de los casos. El valor por defecto de SQS es 10 .
- Valor muy alto: el mensaje puede tardar mucho en llegar a la DLQ, y mientras tanto sigue consumiendo recursos.
La documentación de AWS sugiere configurar
maxReceiveCount lo suficientemente alto como para permitir reintentos suficientes, pero no tanto como para que el mensaje se quede dando vueltas indefinidamente .3.3 La Redrive Policy en formato JSON
Así se ve una Redrive Policy típica:
JSON
{"deadLetterTargetArn": "arn:aws:sqs:us-east-1:123456789012:my-dlq","maxReceiveCount": "5"}
-
deadLetterTargetArn: el ARN (Amazon Resource Name, nombre de recurso de Amazon) de la DLQ. Es el identificador único global del recurso en AWS.
-
maxReceiveCount: el número de recepciones antes de mover a la DLQ.
Implementación paso a paso
4.1 Paso 1: Crear la DLQ
- Entra a la consola de Amazon SQS.
- Crea una nueva cola. Elige el mismo tipo que tendrá la cola de origen (Standard o FIFO).
- Ponle un nombre descriptivo, por ejemplo
my-app-dlq.
- Configura el Message Retention Period (período de retención de mensajes). Este valor debe ser mayor que el de la cola de origen. Si la cola de origen retiene mensajes 4 días, la DLQ debería retenerlos más tiempo, para que no se borren antes de que puedas investigarlos .
4.2 Paso 2: Crear la cola de origen
- Crea otra cola del mismo tipo, por ejemplo
my-app-source-queue.
- Esta es la cola que usarán tus productores y consumidores en el flujo normal.
4.3 Paso 3: Configurar la Redrive Policy en la cola de origen
- Selecciona la cola de origen y haz clic en Edit (Editar).
- Busca la sección Dead-letter queue (cola de mensajes muertos).
- Actívala y selecciona la DLQ que creaste.
- Configura Maximum receives (recepciones máximas) con un valor como
5.
- Guarda los cambios.
Lo que acabas de hacer: le dijiste a SQS que, si un mensaje de
my-app-source-queue se recibe 5 veces sin ser borrado, lo mueva automáticamente a my-app-dlq .4.4 Paso 4: Crear una alarma en CloudWatch
Una DLQ sin monitoreo es inútil: si nadie sabe que hay mensajes ahí, el problema pasa desapercibido.
- Entra a la consola de CloudWatch.
- Ve a Alarms (Alarmas) y crea una nueva.
- Selecciona la métrica
ApproximateNumberOfMessagesVisiblede tu DLQ.
- Configura la condición: mayor o igual a 1 (es decir, que se dispare en cuanto haya al menos un mensaje).
- Configura el período en 1 minuto y los datapoints to alarm (puntos de datos para alarmar) en 1 de 1.
- Como acción, envía una notificación a un tema de Amazon SNS (que puede llegar a correo, Slack, Teams, etc.).
Por qué esto es importante: una alarma en la DLQ te avisa cuando algo empieza a fallar, sin que tengas que revisar manualmente la cola .
Mejores prácticas
5.1 No ignores la DLQ
Una DLQ llena es un cementerio de problemas sin resolver. Revisa periódicamente los mensajes que llegan ahí para:
- Clasificar patrones de fallo: ¿son todos del mismo tipo? ¿Falla siempre un campo concreto?
- Diagnosticar la causa raíz: el mensaje en sí puede contener la pista (un dato inválido, un formato inesperado).
- Decidir si necesitas ajustar el código o los datos .
5.2 Usa el DLQ Redrive para reprocesar
Una vez que hayas corregido el bug que hacía fallar los mensajes, no necesitas volver a enviarlos manualmente. DLQ Redrive (reenvío de DLQ) es una funcionalidad de SQS que permite mover los mensajes de la DLQ de vuelta a la cola de origen (o a otra cola) para que se procesen de nuevo .
Pasos básicos:
- En la consola de SQS, selecciona la DLQ.
- Elige Start DLQ redrive (Iniciar reenvío de DLQ).
- Selecciona la cola de destino (normalmente la cola de origen).
- Configura la velocity (velocidad) a la que se mueven los mensajes. Si tienes muchos, empieza con una velocidad baja para no saturar la cola de origen.
- Inicia el reenvío.
Importante: el reenvío resetea el período de retención. Los mensajes reenviados se consideran mensajes nuevos .
5.3 Cuidado con FIFO y DLQ
Si usas una cola FIFO, ten en cuenta que mover un mensaje a la DLQ rompe el orden estricto. La documentación de AWS advierte que no uses una DLQ con una cola FIFO si no quieres romper el orden exacto de los mensajes o de las operaciones . Si el orden es crítico, necesitarás manejar la compensación a nivel de aplicación.
5.4 Tamaño de lote y mensajes envenenados
Si tu consumidor lee mensajes en lotes (batches) de varios mensajes a la vez (por ejemplo, 10), un solo mensaje defectuoso puede hacer fallar todo el lote. Una buena práctica es procesar cada mensaje del lote de forma individual y usar
batchItemFailures (fallos de elementos del lote) si usas Lambda, para indicar exactamente qué mensajes fallaron y cuáles se procesaron bien. Así evitas que un poison message bloquee los mensajes sanos del mismo lote .
Conclusión
Una DLQ no es un detalle opcional: es una pieza fundamental del diseño de sistemas distribuidos tolerantes a fallos. Sin ella, un solo mensaje defectuoso puede bloquear una cola entera o perderse sin que nadie lo note.
Lo que aprendiste en este artículo:
- Qué es una DLQ: una cola secundaria para mensajes que fallan repetidamente.
- Cómo se configura: con una Redrive Policy en la cola de origen que especifica el ARN de la DLQ y el
maxReceiveCount.
- Cómo monitorearla: con una alarma de CloudWatch sobre la métrica
ApproximateNumberOfMessagesVisible.
- Cómo recuperar mensajes: con DLQ Redrive, una vez corregida la causa del fallo.
Siguiente paso sugerido: crea una cola de origen y una DLQ en tu cuenta de AWS, configura la Redrive Policy con
maxReceiveCount = 3 , y envía un mensaje de prueba. Luego, simula un consumidor que no borra el mensaje (o simplemente no tengas ningún consumidor activo) y observa cómo, tras varios intentos, el mensaje aparece en la DLQ. Verás el patrón funcionando en vivo.Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article