Cómo realmente construyo pipelines de IA por eventos (y la cola que me salvó)
Tabla de contenidos
Un pipeline de IA sin colas es un script con pretensiones. Cuando llega el pico, te das cuenta.
He visto workflows en n8n que funcionan perfecto con pocos eventos y se rompen cuando el volumen crece. No es culpa de n8n. Es culpa de no tener una arquitectura que absorba presión, evite duplicados y recupere errores.
Esta es la arquitectura que usaría para un pipeline de IA por eventos robusto.
Componentes
- n8n: ingesta de webhooks, validación básica, transformación ligera.
- Redis Streams: cola con grupos de consumidores para backpressure.
- Temporal: ejecución durable del procesamiento con reintentos y estado.
- LiteLLM o API directa: llamada al modelo con rate limiting.
- Dead letter queue: eventos que fallan después de varios reintentos.
Cada pieza tiene una responsabilidad clara y puede escalarse por separado.
Reglas de diseño
Idempotencia desde el inicio
Cada evento debe tener un ID único. El worker debe poder ejecutarse varias veces sin duplicar efectos. Esto es crítico porque los reintentos son inevitables.
Validar antes de encolar
No quiero payloads malformados o maliciosos llegando a la cola. Valido HMAC, tamaño, estructura y rate limits en n8n antes de publicar.
No confiar en el LLM para todo
El LLM procesa el contenido, pero la orquestación la maneja Temporal. El modelo no decide cuándo reintentar ni cómo encolar. Eso lo controla el runtime.
Observar la cola, no solo los errores
Métricas que me importan:
- Longitud de la cola.
- Lag de consumidores.
- Latencia de procesamiento.
- Tasa de éxito de workflows.
- Tamaño de la DLQ.
La cola es el termómetro del sistema.
Conclusión
Un pipeline de IA por eventos no es solo n8n conectado a OpenAI. Necesita colas para absorber picos, idempotencia para evitar duplicados, durabilidad para recuperarse, y observabilidad para saber qué pasa.
No es la arquitectura más simple. Pero es la que me dejaría dormir si el pipeline es importante.