Reintentos, idempotencia y colas de descarte: la mitad aburrida de toda automatización

La mitad divertida de una automatización es la parte que funciona. La mitad que decide si alguien se fía de ella es lo que pasa en la tercera llamada fallida a la API de un proveedor a las tres de la madrugada.

Esto vale igual si el flujo vive en n8n, en Make, en una Lambda o en un script de Python en un cron. Los mecanismos son los mismos cuatro, y la mayoría de plataformas no-code no te dan ninguno por defecto.

Idempotencia: la que evita el fallo vergonzoso

Un reintento que duplica un efecto secundario es peor que no reintentar. Dos facturas, dos correos de bienvenida, dos notificaciones a un canal de cliente: esos son los incidentes que la gente recuerda.

El arreglo es una clave de idempotencia: un identificador determinista derivado del evento de negocio, no de la ejecución. factura-2026-0918-ACME-4471, no un UUID generado al principio del flujo, porque una ejecución reintentada genera un UUID nuevo y tira por tierra todo el invento.

Luego tiene que honrarla una de dos cosas. O la API de destino admite una cabecera de idempotencia —Stripe, la mayoría de pasarelas de pago y cada vez más APIs SaaS lo hacen, y deberías estar enviándola— o llevas tú el libro mayor: una tabla con la clave como clave primaria, escrita antes del efecto secundario y consultada al principio. Una violación de la restricción de unicidad no es un error, es el sistema funcionando.

Reintentos: acotados, con espera creciente y solo para los errores correctos

Reintentar un 500 es correcto. Reintentar un 400 es un bucle que correrá hasta que se acabe tu cuota, porque un payload mal formado sigue mal formado lo mandes las veces que lo mandes.

La política que cubre casi todo: reintenta ante 429, 502, 503, 504 y ante tiempos de espera de red; nunca ante 4xx salvo el 429; tres intentos con espera exponencial y jitter —un segundo, cuatro, dieciséis, cada uno más una fracción aleatoria—. El jitter importa cuando una API vuelve de una caída y doscientos flujos encolados reintentan en el mismo segundo; sin él, la tiras tú otra vez.

Respeta Retry-After cuando la respuesta lo trae. Es la API diciéndote exactamente lo que quieres saber.

Colas de descarte: donde un fallo espera a una persona

Después del último reintento, la ejecución tiene que ir a algún sitio que no sea una línea de log. Una cola de descarte puede ser una cola SQS, una tabla o un canal dedicado; lo que importa es que guarde el payload de entrada completo, el error, la marca de tiempo y la clave de idempotencia, y que una persona pueda reinyectar desde ahí.

La reinyección es la parte que los equipos se saltan y luego lamentan. Si recuperarse de una caída de dos horas significa que alguien vuelva a meter cuarenta registros a mano, la automatización no sobrevivió a su primer mal día. Un script de reinyección que lee la tabla de descartes y reenvía es una hora de trabajo y es la diferencia entre un incidente y un no-evento.

La alerta tiene que nombrar el evento de negocio

«Ha fallado el flujo 47» despierta a alguien que luego tiene que abrir un navegador para averiguar si importa. «12 facturas de proveedor no se han contabilizado desde las 02:10» se tría en la propia notificación.

Alerta sobre el agregado, no sobre cada fallo: un mensaje por ejecución fallida a las tres de la mañana es la forma de que se silencie un canal, y un canal silenciado es la forma de tener una caída de tres días. Alerta por tasa y por antigüedad: más de N fallos en diez minutos, o cualquier cosa en la cola de descarte con más de una hora.

Y alerta sobre el silencio. El modo de fallo que nadie instrumenta es el flujo que dejó de dispararse: el webhook que se desregistró, la programación que se desactivó en una sesión de depuración hace ocho semanas. Una comprobación que salte cuando un flujo lleva sin ejecutarse más del doble de su intervalo esperado caza toda una familia de caídas que no producen ningún error, porque no se ejecutó nada.

Dónde vive esto en cada herramienta

En n8n, un flujo con Error Trigger recoge los fallos de toda la instancia y es el sitio natural para escribir el descarte y lanzar la alerta. En Make, es una ruta de error explícita por módulo falible con directiva Break. En tu propio código es la cola que ya operas. La plataforma importa menos que si existen los cuatro mecanismos; en la mayoría de cuentas que auditamos existen cero o uno.

Qué hacer esta semana

Elige la automatización cuyo fallo más molestaría a un cliente. Fuerza un fallo en preproducción —apúntala a un host que no resuelva— y mira qué pasa. Luego responde a tres preguntas: ¿se enteró alguien?, ¿la entrada sigue siendo recuperable? y, si la ejecutas dos veces, ¿el cliente recibe dos de algo?