Pub/Sub: Dead Letter Queue (DLQ) (Resiliencia Ante Errores)
Autor: Eduardo Martínez Agrelo
En un entorno de producción, las cosas fallan: una base de datos puede estar fuera de servicio temporalmente o un mensaje puede llegar corrupto. En este laboratorio, aprenderemos a implementar una Dead Letter Queue (DLQ), una técnica esencial para evitar que un error puntual bloquee todo nuestro pipeline de datos.
¿Qué es una Dead Letter Queue?
Una DLQ es un Topic especial que actúa como una "zona de cuarentena". Cuando un mensaje no puede ser procesado tras varios intentos, Pub/Sub lo retira de la circulación principal y lo envía a esta cola de mensajes muertos:
- Evitar el Veneno de Mensaje (Poison Message): Impide que un mensaje corrupto se reintente infinitamente, consumiendo recursos sin éxito.
- Auditabilidad: Permite a los ingenieros inspeccionar los mensajes fallidos manualmente para corregir errores en el código o en los datos.
Políticas de Reintento y Max Delivery Attempts
La clave de la resiliencia es el control sobre los reintentos. Mediante Terraform, definiremos una política que limita cuántas veces Pub/Sub intentará entregar el mensaje antes de rendirse:
- max_delivery_attempts: El número de fallos permitidos (normalmente entre 5 y 100) antes de mover el mensaje a la DLQ.
- Ack Deadline: El tiempo que Pub/Sub espera antes de considerar que un mensaje ha fallado si no recibe confirmación.
Configuración de Permisos IAM
Mover un mensaje de una suscripción a otro Topic requiere permisos. Es un error común olvidar que la Service
Account interna de Pub/Sub necesita permisos de publisher sobre el Topic de la DLQ y de
subscriber sobre la suscripción original. Automatizaremos estos permisos en nuestro archivo de
Terraform para garantizar un flujo sin fricciones.
Implementación práctica
Simularemos un fallo real en Python. Crearemos un consumidor que recibe mensajes pero nunca envía el
ack(). Veremos en tiempo real cómo Pub/Sub reintenta la entrega hasta alcanzar nuestro límite
configurado, momento en el cual el mensaje "desaparecerá" de la cola activa para aparecer en nuestro Topic de
auditoría (DLQ).
Conclusión: Tu arquitectura es ahora a prueba de balas
Has transformado un sistema frágil en una arquitectura resiliente capaz de autogestionar sus errores. Ahora que dominas el flujo de mensajes individuales y sus fallos, es hora de cambiar de escala. En el siguiente laboratorio, aprenderemos a procesar mensajes de forma masiva mediante Jobs de tipo Batch.