Orquestar n8n con webhooks que no se caen a las 3 AM

El patron se repite casi igual en cada hilo donde alguien pregunta por que su flujo "funciona bien en pruebas y se cae de noche". El nodo principal esta bien armado, los prompts estan probados, la logica de transformacion no tiene nada raro. Lo que falla es la puerta de entrada: un webhook que recibe datos de un tercero y que asume, sin decirlo, que ese tercero siempre va a responder rapido y con un 200.

Cuando el proveedor externo se demora cuarenta segundos o devuelve un 502 intermitente, n8n reintenta segun la configuracion del nodo, pero si el trigger ya consumio el evento y lo marco como procesado, ese payload se pierde. A las 3 AM nadie esta mirando el panel, y a las 9 AM aparece el reclamo del cliente que no recibio su confirmacion. La mayoria de las caidas reales que vemos en el foro no son del agente ni del modelo: son de esa frontera entre el mundo externo y el flujo.

Separar el trigger del procesamiento pesado

La primera decision estructural es no hacer todo dentro del mismo workflow que recibe el webhook. Conviene un flujo corto que solo valida, encola y responde 200 al proveedor en menos de un segundo, y otro flujo distinto que consume esa cola y hace el trabajo lento: llamadas a APIs, embeddings, escritura en base de datos. Con Redis o incluso una tabla de Postgres como cola simple alcanza para empezar. El trigger deja de ser el cuello de botella y el proveedor externo no se queda esperando mientras tu agente piensa.

En Make el patron es parecido pero el limite de operaciones por minuto aparece antes. Cuando el volumen sube a miles de ejecuciones diarias, la diferencia entre n8n self-hosted y Make se nota sobre todo en el control de concurrencia: en n8n puedes limitar workers y definir cuantas ejecuciones simultaneas quieres, en Make dependes del plan y de la cola del proveedor. No es que uno sea mejor, es que el punto de quiebre llega en momentos distintos.

Idempotency keys: el seguro contra duplicados

Si el proveedor reintenta porque no recibio tu 200, vas a recibir el mismo evento dos veces. Sin una clave de idempotencia por evento, terminas enviando dos correos, creando dos registros o cobrando dos veces. La solucion es simple: guardar el id del evento externo en una tabla con indice unico y descartar lo que ya existe. En n8n eso es un nodo de Postgres o Redis con un check previo, no mas de cinco lineas de logica. Suena obvio hasta que revisas cuantos flujos en produccion no lo tienen.

Dead letter: no perder payloads silenciosamente

Cuando un evento falla tres veces, la tentacion es descartarlo. Mejor guardarlo en una cola de dead letter con el payload completo, el error y la marca de tiempo. Asi puedes reprocesar en lote al dia siguiente sin pedirle al cliente que vuelva a enviar nada. Este nodo de dead letter es el que separa un prototipo de fin de semana de algo que aguanta un lunes con trafico real.

Nada de esto requiere salir de no-code. Requiere aceptar que la confiabilidad no viene del nodo mas vistoso sino de las decisiones aburridas: cola, idempotencia, dead letter y separacion de responsabilidades. Si estas armando algo parecido, en el siguiente hilo sobre RAG y bases vectoriales discutimos cuando conviene agregar esa capa y cuando solo suma latencia.