La espina dorsal aburrida: webhooks, colas y workers detrás de toda automatización que sobrevive

Las plataformas de automatización esconden una arquitectura. Ese es su valor: obtienes un endpoint de webhook, un lienzo y un motor de ejecución sin construir nada de eso. También es por lo que la primera caída seria desconcierta: el fallo está en una capa de la que nadie del equipo tiene un modelo mental.

El modelo es sencillo y conviene tenerlo, estés con n8n, con Make o con algo escrito por ti.

Las tres piezas

Una entrada que acepta y confirma rápido. El único trabajo de un receptor de webhooks es validar la petición, escribirla en algún sitio duradero y devolver un 200 en unos milisegundos. Nada más. Si tu entrada trabaja antes de confirmar, cada paso lento es visible para quien envía como un tiempo de espera agotado, y quien envía responde a eso reintentando: o sea, que tu endpoint lento recibe ahora el triple de tráfico en su peor momento.

Una cola en medio. Absorbe los picos, desacopla el ritmo de quien envía del tuyo de procesar y conserva el trabajo entre reinicios. Es la pieza que convierte un pico en un retraso en vez de en una pérdida de datos.

Workers que procesan. Sin estado, escalables horizontalmente y —esto es lo crítico— con un límite de concurrencia marcado por lo que toleran los sistemas de destino, no por tu CPU. Casi todas las caídas autoinfligidas en automatización son un grupo de workers acertando demasiado rápido contra una API que limita la frecuencia.

Todo lo demás —reintentos, descartes, programación— cuelga de estas tres.

Las cinco decisiones

1. Confirma antes de procesar, siempre. El contrato con quien envía es «te lo he entregado». Todo lo que hagas antes de devolver el 200 está en el camino crítico del sistema de otro.

2. Verifica la firma y rechaza lo no firmado. Un endpoint de webhook es una puerta pública y no autenticada hacia tus procesos de negocio. Casi todos los proveedores firman sus payloads; casi todas las integraciones que auditamos se saltan la verificación porque funcionaba sin ella durante las pruebas. Verifica, y compara en tiempo constante.

3. Di en voz alta tu semántica de entrega. Las colas te dan al-menos-una-vez; exactamente-una-vez es un cuento que se cuenta la gente. Acepta el duplicado y haz idempotente el procesado: la mecánica está aquí. Cualquier diseño que dependa de que un mensaje llegue exactamente una vez es un diseño que producirá una factura duplicada.

4. El orden importa menos de lo que crees, hasta que importa. Si un evento «cliente actualizado» puede adelantar a «cliente creado», necesitas una clave de partición —normalmente el identificador de la entidad— para que los eventos de una entidad mantengan el orden mientras entidades distintas se procesan en paralelo. El orden global no compensa y destroza el rendimiento; el orden por clave es barato y casi siempre es lo que el negocio quería decir.

5. Acota todo. Un tamaño máximo de mensaje, un tiempo de invisibilidad mayor que tu ejecución realista más lenta, un número máximo de recepciones que mande el mensaje envenenado a la cola de descarte. Un sistema sin cotas falla de formas que exigen una base de datos para diagnosticarse.

Dónde pone cada plataforma estas piezas

En el modo cola de n8n la arquitectura es exactamente esta —instancia principal como entrada, Redis como cola, workers como workers—, y por eso el modo cola no es opcional en producción; está en n8n autoalojado. En Make y Zapier las piezas existen pero son del fabricante, así que tus palancas son la programación, los filtros y las rutas de error. En código propio son SQS más Lambda, o Pub/Sub más Cloud Run, y todo junto son cuarenta líneas de Terraform.

Lo único que las plataformas no harán por ti

Presión hacia atrás, hacia el origen. Cuando la profundidad de tu cola crece más rápido de lo que los workers la vacían, algo tiene que ceder: o escalas workers, o descartas y le dices a quien envía que baje el ritmo. Un sistema sin ninguna señal simplemente acumula hasta que un tiempo de espera en algún punto convierte el retraso en pérdida de datos.

Alerta por profundidad de cola y por antigüedad del mensaje más viejo. La antigüedad es la mejor métrica: una profundidad de diez mil que se vacía en un minuto está bien, una de cuarenta cuyo más viejo tiene dos horas significa que el procesado se ha parado.

Qué hacer esta semana

Busca tu endpoint de webhook con más tráfico y mide cuánto tarda en devolver el 200. Si la respuesta pasa de un par de cientos de milisegundos, hay trabajo ocurriendo antes de la confirmación, y el arreglo —aceptar, encolar, devolver— suele ser una tarde y elimina una categoría entera de incidentes.