Arquitecturas de datos: por qué separar la capa de ingestión de la de enriquecimiento salva pipelines
Arquitecturas de datos: por qué separar la capa de ingestión de la de enriquecimiento salva pipelines
Hay un error de diseño que se repite en equipos con buena intención técnica: juntar la ingestión de señales con su enriquecimiento en el mismo paso del pipeline. Al principio parece eficiente. En producción, cuando una API externa tarda más de lo previsto o devuelve un error transitorio, todo el flujo se detiene. Y lo que se detiene no es solo el enriquecimiento — también se pierden señales que no volverán.
Ese acoplamiento tiene un coste que no aparece en el diseño inicial pero sí aparece en el postmortem.
El problema del pipeline monolítico en análisis de señales externas
Cuando el equipo decide que cada señal que llega desde una fuente pública debe pasar por normalización, clasificación y enriquecimiento antes de ser almacenada, está tomando una decisión de arquitectura que parece limpia. Un solo paso, datos ya listos para consultar.
El problema es que esa cadena tiene múltiples dependencias externas simultáneas: la API de análisis semántico, el servicio de geolocalización, el modelo de categorización sectorial. Cada una tiene su propia disponibilidad, su propio rate limit, su propia latencia variable.
Cuando cualquiera de esas dependencias falla o se ralentiza, el pipeline monolítico tiene dos opciones: bloquear o descartar. Ninguna es aceptable cuando las señales tienen ventana temporal — si no las procesas ahora, no existen en el futuro con el mismo contexto.
La solución: dos capas con contratos distintos
La separación no es una idea nueva, pero su implementación concreta en pipelines de análisis mediático sí tiene matices que vale la pena detallar.
Capa 1 — Ingestión cruda:
Su único objetivo es recibir, persistir y confirmar. Nada más. La señal entra, se escribe en un almacén intermedio (una cola durable, un bucket de objetos, un log compactado) y se confirma la recepción. Esta capa no llama a ninguna API externa. No transforma. No filtra salvo por condiciones de integridad básica (payload mínimo válido, timestamp presente).
Si esta capa falla, el problema es de infraestructura propia, no de dependencias externas. Mucho más controlable.
Capa 2 — Enriquecimiento asíncrono:
Lee desde el almacén intermedio, aplica transformaciones, llama a las APIs de enriquecimiento, escribe el resultado en el destino final. Opera sobre datos ya persistidos, con lo que puede reintentar sin riesgo de perder la señal original. Puede escalar horizontalmente de forma independiente. Puede aplicar estrategias de backoff agresivo sin que eso afecte al flujo de entrada.
El contrato entre capas es simple: el formato del almacén intermedio. Ese contrato debe estar versionado y documentado internamente.
Dimensionar el almacén intermedio correctamente
El almacén que separa las dos capas es el punto más crítico de esta arquitectura. Un error común es dimensionarlo para el tráfico promedio, no para el pico más el tiempo de recuperación de una caída del enriquecimiento.
Algunos parámetros que hay que calcular antes de elegir la tecnología:
- Tasa máxima de entrada en condiciones de pico (no promedio).
- Tiempo estimado de indisponibilidad de las APIs de enriquecimiento, basado en el histórico del proveedor o en el SLA contratado.
- Tamaño medio de payload por señal, para calcular el espacio total en un escenario de degradación prolongada.
Si el pipeline procesa 40.000 señales por hora en pico, y la API de enriquecimiento puede estar caída hasta 4 horas según el SLA del proveedor, el almacén necesita absorber al menos 160.000 payloads sin perder datos y sin aplicar backpressure a la capa de ingestión. Ese es el número mínimo de partida, no el objetivo de optimización.
Gestión de esquemas: el punto que se olvida casi siempre
Cuando la capa de ingestión persiste señales crudas y la capa de enriquecimiento las lee semanas después (porque hubo un fallo largo o una reconfiguración del modelo), el esquema de la señal cruda puede haber cambiado.
Esto provoca fallos silenciosos: el enriquecimiento no falla con error, simplemente produce campos vacíos o valores incorrectos porque el mapeado dejó de ser válido.
La solución es obligar a que cada payload crudo lleve su versión de esquema embebida. No como campo opcional — como campo requerido que el consumidor valida antes de procesar. Si la versión no es compatible, el mensaje va a una dead-letter queue con contexto suficiente para inspeccionarlo manualmente o reprocesarlo cuando el nuevo mapeado esté listo.
Este patrón es especialmente relevante cuando se consumen señales desde APIs que evolucionan, como las que expone FeedScale, donde el esquema de respuesta puede añadir campos o ajustar estructuras anidadas entre versiones.
Monitorización independiente por capa
Si solo monitorizas el pipeline de extremo a extremo, no sabrás dónde está el cuello de botella cuando la latencia suba. Las métricas deben separarse:
- Capa de ingestión: tasa de entrada, tasa de escritura confirmada, lag entre recepción y persistencia.
- Almacén intermedio: profundidad de la cola, tasa de consumo, edad del mensaje más antiguo no procesado.
- Capa de enriquecimiento: tasa de procesamiento, tasa de error por API externa, tiempo medio de enriquecimiento por señal.
La métrica más útil para detectar problemas antes de que escalen es la edad del mensaje más antiguo no procesado en el almacén intermedio. Si ese número crece sostenidamente aunque no haya errores visibles, la capa de enriquecimiento está perdiendo terreno frente a la ingestión. Es la señal de que hay que escalar consumidores o revisar la latencia de las APIs externas.
Cuándo esta arquitectura no tiene sentido
No todo pipeline necesita este nivel de separación. Si el volumen de señales es bajo (menos de unos pocos miles por hora), si las APIs de enriquecimiento tienen disponibilidad demostrada superior al 99,9 % y si la tolerancia a pérdidas es alta, el pipeline monolítico puede ser válido y más fácil de operar.
La separación en capas introduce complejidad operativa real: más componentes, más contratos que mantener, más métricas que observar. Esa complejidad solo se justifica cuando el coste de perder señales o de tener el pipeline bloqueado supera el coste de mantener la arquitectura separada.
El punto de inflexión suele llegar cuando el equipo tiene su primera caída importante de una API externa en producción. Después de eso, la conversación sobre separar capas deja de ser teórica.
Si estás diseñando o revisando un pipeline de análisis de señales públicas, la pregunta correcta no es "¿necesito esta complejidad?" sino "¿cuánto me cuesta la próxima vez que la capa de enriquecimiento falle durante cuatro horas?". Pon ese número encima de la mesa antes de decidir.