Pipeline IA Eventos: Arquitectura Producción

Parte 1 de 3. Parte 2 | Parte 3

El trimestre pasado, depuré una caída en producción donde un pico de eventos de webhooks de clientes colapsó nuestro pipeline de IA. Habíamos construido un workflow n8n → LLM que funcionaba bien para 10 eventos al día. Cuando una campaña de marketing generó 10,000 eventos en una hora, el pipeline colapsó: llamadas duplicadas a LLM quemaron $4k en costos de API, eventos perdidos generaron clientes enojados, y sin manejo de errores no podíamos recuperar los jobs fallidos. Pasamos 12 horas reprocesando eventos manualmente sin visibilidad de qué falló. Ahí entendí que un pipeline de IA confiable necesita colas, idempotencia, manejo de errores y observabilidad desde el día uno.

Desde entonces he desplegado esta arquitectura en 6 clusters de Kubernetes en producción, procesando entre 1,000 y 1.2 millones de eventos por día. Cada cluster ejecuta el mismo stack con ajustes para escala y compliance. A continuación está la arquitectura, código y configuración exactos que uso.

¿Qué es un Pipeline de IA Basado en Eventos?

Un pipeline de IA basado en eventos es un sistema donde triggers externos (webhooks, cambios en base de datos, colas de mensajes o cron jobs) inician workflows automatizados que procesan datos usando large language models (LLMs). A diferencia del procesamiento por lotes, estos pipelines manejan volúmenes impredecibles y deben garantizar procesamiento al-menos-una-vez sin duplicados.

Los casos de uso incluyen enrutamiento de tickets de soporte, moderación de contenido en tiempo real, scoring de leads y generación de emails personalizados. He desplegado estos pipelines para clientes de e-commerce, SaaS y fintech, cada uno con distintos volúmenes y requisitos de compliance (GDPR, HIPAA, SOC2).

La diferencia entre un pipeline de hobby y uno de producción son las garantías: no perder eventos, no hacer llamadas duplicadas a LLM y poder recuperar fallos.

Visión General de la Arquitectura

La arquitectura que he desplegado en Kubernetes sigue este flujo:

graph TD
    A[Webhooks Externos] -->|HTTPS + Validación HMAC| B[Nodo de Ingesta n8n]
    B -->|Transformar y Validar Payload| C[Cola Redis Streams]
    C -->|Grupos de Consumidores| D[Temporal Worker]
    D -->|Procesar y Reintentar| E[API de LLM]
    E -->|Resultado| F[Sistema de Destino]
    C -->|Fallido Después de 5 Reintentos| G[Dead Letter Queue]
    D -->|Error Transitorio| H[Reintento con Backoff Exponencial]
    I[Prometheus] -->|Scrapear Métricas| B
    I -->|Scrapear Métricas| C
    I -->|Scrapear Métricas| D

Cada componente tiene un trabajo claro:

• n8n: Ingesta ligera de webhooks, transformación de payloads y validación básica.
• Redis Streams: Buffer para picos de tráfico y backpressure, con grupos de consumidores.
• Temporal: Orquestación de workflows largos, reintentos, gestión de estado y visibilidad.
• LLMs: Procesan el payload final. Temporal maneja rate limiting y circuit breaking.

Cada componente está desacoplado. Puedes escalar o reemplazar cada uno por separado.

FAQ

¿Cuál es la diferencia entre procesamiento al-menos-una-vez y a-lo-más-una-vez?

Al-menos-una-vez garantiza que un evento se procese una o más veces (posibles duplicados). A-lo-más-una-vez garantiza 0 o 1 veces (los eventos pueden perderse). Para pipelines de IA, siempre uso al-menos-una-vez con idempotencia. Perder un ticket de soporte o una notificación de pago es peor que procesarlo dos veces.

¿Por qué usar Redis Streams en lugar de una lista simple de Redis?

Redis Streams soporta grupos de consumidores que permiten a varios workers compartir la carga, rastrear mensajes pendientes y recuperarse de caídas. Las listas simples pierden mensajes si un worker muere a mitad del procesamiento. Lo aprendí por las malas en mi primer despliegue.

¿Cómo mejora Temporal la fiabilidad comparado con n8n solo?

n8n es bueno para ingesta pero no tiene soporte nativo para workflows largos, reintentos complejos u orquestación stateful. Temporal maneja todo eso. He visto pipelines solo con n8n perder eventos silenciosamente cuando los workflows duran más de 5 minutos. Temporal los mantiene vivos por días si es necesario.

¿Qué métricas debería rastrear para la salud del pipeline?

Rastreo longitud de cola, lag de consumidores (XINFO GROUPS en Redis Streams), latencia de API de LLM, tasa de error, tamaño de DLQ y tasa de éxito de workflows de Temporal. Estas seis métricas te dicen exactamente cuándo escalar o depurar.

¿Puedo escalar esta arquitectura a más de 1M eventos por día?

Sí. He llegado a 1.2 millones de eventos por día con 5 workers de Temporal y 3 shards de Redis. La arquitectura escala horizontalmente por diseño.

Partes in this series: Parte 2 →