iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Un mensaje que no se puede procesar no debería decidir cuánto tarda el resto de tu cola. Para evitarlo hacen falta cinco decisiones que funcionan juntas: clasificar los errores, limitar los reintentos con backoff, mover los mensajes agotados a una dead-letter queue (DLQ) o dead-letter topic (DLT), recuperarlos con control y comprobar que el patrón elegido respeta el orden que necesita tu negocio. Ninguna pieza basta por sí sola, y no existe un número de intentos válido para todos los sistemas.
Por qué un mensaje tóxico congela el flujo
Un mensaje tóxico (poison message) es aquel que el consumidor no puede procesar y que vuelve a entregarse una y otra vez. El daño no lo causa solo el mensaje, sino lo que queda detrás de él: si el consumidor insiste en el mismo mensaje antes de avanzar, el resto de la cola o de la partición espera.
Cada broker lo manifiesta de forma distinta:
- Amazon SQS. Un mensaje no confirmado reaparece cuando expira su periodo de visibilidad, y cada recepción suma un intento. Sin un límite, el ciclo no tiene fin.
- Kafka con Spring Kafka. Un reintento que se hace en el mismo consumidor deja la partición detenida en el offset que falla.
- RabbitMQ quorum queues. El broker lleva un contador de entregas fallidas por mensaje, y ese contador es lo que permite cortar el ciclo.
Paso 1: clasifica el error antes de reintentar
Reintentar solo tiene sentido cuando el error puede desaparecer con el tiempo. Conviene separar dos familias:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute| Tipo de fallo | Ejemplos | Tratamiento recomendado |
|---|---|---|
| Transitorio | Dependencia que no responde a tiempo, límite de tasa temporal, bloqueo breve de base de datos | Reintento acotado con backoff |
| Permanente o determinista | Mensaje mal formado, payload que no cumple el esquema esperado, datos que el consumidor no puede interpretar | Enrutar directamente a la DLQ o DLT sin reintentar; corregir datos o código antes de reprocesar |
Para esta separación hay soporte explícito en algunas plataformas. Spring Kafka permite marcar excepciones que no deben reintentarse, de modo que pasen directamente al DLT; el funcionamiento del patrón de retry topics está descrito en su documentación oficial. Kafka Connect trata los reintentos, la tolerancia a errores y la DLQ como comportamiento configurable; en su guía de usuario aparecen opciones como errors.tolerance y errors.deadletterqueue.topic.name.
#1 Best Overall
Paso 2: limita los intentos y aplica backoff
No hay un número universal de reintentos. El límite debe salir de dos datos concretos: cuánto tarda en recuperarse la dependencia típica y cuánta demora tolera tu SLA. Por ejemplo, si una API externa suele volver en unos minutos, cinco reintentos separados por milisegundos se agotan antes de que la API se recupere; cien reintentos sin pausa solo ocupan al consumidor. El backoff alarga la espera entre intentos, y el límite pone fin al ciclo. Necesitas ambos.
Cada plataforma expresa el límite de manera distinta.
Amazon SQS: redrive policy y maxReceiveCount
La documentación de dead-letter queues de Amazon SQS describe la redrive policy como la regla que envía mensajes a una DLQ después de que la cola de origen no logre procesarlos un número determinado de veces. Ese número se fija con maxReceiveCount: cada recepción del mensaje cuenta, y al alcanzar el límite el mensaje pasa a la DLQ. La documentación lo formula así: “The redrive policy redirects messages to a dead-letter queue after the source queue fails to process a message a specified number of times.”
Spring Kafka: intentos, backoff y excepciones no reintentables
Spring Kafka permite especificar cuántos intentos se hacen y con qué backoff. Sus retry topics escalonados aplican backoff exponencial, y el mensaje que agota sus intentos llega al DLT. Antes de fijar cifras, marca como no reintentables las excepciones que nunca se resolverán por esperar; así no consumen intentos que no sirven para nada.
Rank #3
RabbitMQ quorum queues: delivery-limit
Las quorum queues llevan un contador de entregas fallidas por mensaje. El argumento delivery-limit fija el máximo que se tolera; al superarlo, el mensaje se gestiona según la estrategia de dead-lettering configurada, normalmente con un dead-letter exchange (DLX). Los límites y las garantías de dead-lettering dependen de la versión y de la configuración, por lo que conviene leer la documentación de quorum queues de RabbitMQ 4.2 correspondiente a la versión que usas.
Amazon SNS: reintentos de entrega, no de procesamiento
Amazon SNS documenta reintentos con backoff y una DLQ para las entregas que fallan, según la documentación de dead-letter queues de SNS. Ese mecanismo actúa entre el topic y el suscriptor. No sustituye la clasificación de errores de tu consumidor: un mensaje puede entregarse correctamente a la suscripción y, aun así, fallar en tu código.
Paso 3: aísla el mensaje y guarda contexto para diagnosticarlo
Cuando se agotan los intentos, el mensaje debe salir del flujo principal hacia la DLQ o DLT y llegar con suficiente información para investigarlo sin volver a ejecutar todo el sistema. Como mínimo, conserva:
- el error o excepción final y su clase;
- la cola, topic o partición de origen, con su offset o identificador;
- el número de intentos realizados;
- identificadores de correlación que enlacen con logs y trazas.
Esta lista es una práctica recomendada, no una garantía de la plataforma. Kafka Connect puede habilitar headers de contexto en los registros que van a la DLQ, pero no todas las implementaciones guardan los mismos metadatos ni ofrecen las mismas garantías, así que confirma qué se persiste realmente en tu versión.
La DLQ también necesita observabilidad propia. Alerta sobre su profundidad y sobre la antigüedad del mensaje más viejo: una DLQ que crece en silencio es un fallo que nadie ve.
Paso 4: recupera con control
La DLQ no corrige nada por sí misma; solo aísla el problema. El redrive, es decir, el reenvío de mensajes desde la DLQ, es una operación aparte, y puede volver a saturar el pipeline si se ejecuta sin medir.
- Lee el error y el contexto guardados en la DLQ o DLT. Determina si la causa era transitoria (y ya desapareció) o determinista (requiere cambiar datos o código).
- Corrige lo que corresponda: código del consumidor, esquema, datos de origen o disponibilidad de la dependencia. Reenviar antes de corregir solo repite el fallo.
- Reenvía un lote pequeño. La documentación de configuración del redrive de SQS recomienda empezar con una velocidad baja.
- Vigila el consumidor, la tasa de errores, la latencia y la cola o topic de destino mientras el lote avanza.
- Sube la velocidad de forma gradual. En SQS puedes elegir la velocidad máxima del sistema o una velocidad personalizada; usa la máxima solo cuando hayas comprobado que el destino la soporta.
Límites del redrive en Amazon SQS
- El destino puede ser la cola de origen o un destino distinto. Vuelve a la cola de origen si el mensaje debe procesarse igual; desvíalo si necesita otro tratamiento.
- El redrive no permite filtrar ni modificar mensajes durante el movimiento. Si necesitas transformar o seleccionar, usa un flujo separado: leer, transformar y republicar.
- Es una operación gestionada con permisos y límites propios. Revisa la configuración del redrive antes de automatizarlo.
Paso 5: decide cuándo manda el orden
Los patrones de reintento no son intercambiables. Si el negocio exige orden por clave o por partición, el reintento que más protege ese orden es el que bloquea: el consumidor se queda en el mensaje hasta resolverlo, y lo que viene detrás espera. Es exactamente el comportamiento que queremos evitar con un mensaje tóxico, así que el compromiso es explícito. Lo que no existe es un patrón que preserve el orden y, a la vez, deje avanzar al resto sin tocar esa secuencia.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Retry topics no bloqueantes (Spring Kafka). Liberan el flujo principal al mover el reintento a otros topics, pero pierden garantías de orden para el topic.
- DLQ asociada a una cola FIFO (Amazon SQS). AWS advierte que puede romper el orden exacto de mensajes u operaciones.
Define por escrito qué orden debe preservarse (por clave, por partición o global) y elige el patrón según ese requisito, aceptando su costo: bloqueo o desorden. Cada producto define sus garantías, así que no traslades una regla de un broker a otro sin comprobarla.
Comparativa de implementaciones
Antes de comparar, asume que un reintento puede producir duplicados salvo que tu plataforma diga lo contrario; las páginas citadas no establecen las mismas garantías de entrega para todas. Para Kafka, decide primero si la solución será Kafka Connect, Spring Kafka u otra configuración, porque sus mecanismos difieren. La tabla resume lo que la documentación citada establece en cada caso.
Quick Recap
| Eje | Amazon SQS | Spring Kafka | RabbitMQ quorum queues | Kafka Connect |
|---|---|---|---|---|
| Límite de intentos | maxReceiveCount en la redrive policy |
Intentos configurables; excepciones no reintentables | delivery-limit sobre el contador de entregas fallidas |
Reintentos configurables; valores según el conector y la versión |
| Backoff | No indicado en la documentación citada | Backoff exponencial en retry topics escalonados | No indicado en la documentación citada | Reintentos configurables; detalle de backoff no indicado en la documentación citada |
| Orden | Una DLQ asociada a FIFO puede romper el orden exacto | Retry topics no bloqueantes pierden garantías de orden | No indicado en la documentación citada | No indicado en la documentación citada |
| Destino de fallos y redrive | DLQ; redrive a la cola de origen u otro destino, con velocidad configurable | DLT; redrive no indicado en la documentación citada | Dead-lettering mediante DLX | DLQ configurable; headers de contexto opcionales |
| Permisos y límites | Redrive con permisos y límites propios | No indicado en la documentación citada | Depende de la versión y la configuración | No indicado en la documentación citada |
Síntomas y primera comprobación
- El consumidor reintenta el mismo offset sin avanzar. Revisa si el error está clasificado como permanente y si existe un límite de entregas; sin límite, el ciclo continúa indefinidamente.
- La DLQ crece después de cada despliegue. Suele tratarse de un fallo determinista, como un cambio de esquema. Lee el error de los primeros mensajes antes de planear cualquier redrive.
- Tras un redrive aparecen errores en cascada o latencia alta. El lote fue demasiado grande o la velocidad demasiado alta. Pausa el reenvío, baja la velocidad y revisa la cola o topic de destino.
- Mensajes de una misma clave llegan desordenados. El patrón elegido no preserva el orden. Revisa el paso 5 y la garantía de tu broker para ese caso.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
