Arquitecturas de datos: cómo decidir qué latencia es aceptable antes de construir el pipeline
Arquitecturas de datos: cómo decidir qué latencia es aceptable antes de construir el pipeline
Nadie discute la latencia hasta que el pipeline ya está en producción y alguien del negocio pregunta por qué los datos llegan tarde. En ese momento, la conversación se vuelve costosa: refactorizar una arquitectura orientada a batch para convertirla en near-real-time puede implicar semanas de trabajo, cambios en la capa de ingestión, en el procesamiento y en la forma en que los consumidores leen los datos.
El problema no es técnico, o no solo. Es de diseño prematuro: se construye el pipeline antes de formalizar qué significa "a tiempo" para cada caso de uso. Y ese concepto no es universal. En un sistema de alertas de crisis reputacional, cinco minutos de retraso pueden invalidad el valor del dato. En un pipeline de análisis de tendencias editoriales, treinta minutos son perfectamente aceptables.
Definir el umbral de latencia tolerable antes de elegir la arquitectura no es burocracia técnica. Es la decisión que más condiciona el coste, la complejidad y la mantenibilidad de todo lo que viene después.
El error de asumir que más rápido siempre es mejor
La intuición lleva a muchos equipos a aspirar a real-time por defecto. Parece la opción "más segura": si el sistema puede procesar en tiempo real, también puede procesar en batch. La lógica es razonable, pero el coste no.
Un sistema genuinamente real-time requiere infraestructura de streaming (Kafka, Kinesis, Flink o similares), lógica de procesamiento sin estado o con estado gestionado, y tolerancia explícita a mensajes fuera de orden, duplicados y retrasos en las fuentes upstream. Cada uno de esos requisitos añade complejidad operativa.
Si el caso de uso real acepta datos con quince minutos de margen, construir streaming introduce complejidad sin valor. Y esa complejidad acaba siendo deuda: aumenta el tiempo de depuración, dificulta el onboarding de nuevos ingenieros y multiplica los puntos de fallo potenciales.
La pregunta correcta no es "¿podemos hacerlo en tiempo real?" sino "¿qué latencia máxima deja de tener valor para el consumidor final de este dato?".
Cómo formalizar el SLO de latencia antes de diseñar
Un Service Level Objective (SLO) de latencia no es un número arbitrario. Se deriva de tres factores concretos:
1. La frecuencia de decisión del consumidor del dato. Si el equipo que consume el análisis revisa dashboards cada hora, un pipeline que entrega cada veinte minutos es más que suficiente. Si el sistema dispara alertas automáticas, el umbral puede bajar a segundos.
2. La volatilidad de la señal. Algunos tipos de señales del universo público de Internet cambian muy rápido: una mención viral puede acumular miles de interacciones en minutos. Otras, como tendencias editoriales o patrones de cobertura sectorial, evolucionan en horas o días. La arquitectura debe ajustarse al ritmo de la señal, no al revés.
3. El coste marginal de reducir la latencia. Existe una curva entre latencia y coste de infraestructura que rara vez se dibuja explícitamente. Pasar de batch horario a batch cada diez minutos puede implicar un incremento mínimo. Pasar de ahí a near-real-time puede multiplicar el coste por tres. El equipo de arquitectura debe conocer esa curva antes de comprometerse con ningún diseño.
Con esos tres factores sobre la mesa, el SLO de latencia se convierte en un contrato técnico negociable, no en una aspiración vaga.
Patrones arquitectónicos según el umbral definido
Una vez que el umbral está formalizado, la elección del patrón se simplifica considerablemente.
Batch clásico (>30 minutos de tolerancia). El patrón más sencillo de operar. Adecuado para análisis históricos, informes periódicos y enriquecimiento de señales que no requieren reacción inmediata. La ingestión desde APIs externas se programa con intervalos fijos, los datos se procesan en bloques y los consumidores leen desde un almacén ya estabilizado.
Micro-batch o near-real-time (5-30 minutos). Aquí entran arquitecturas basadas en ventanas temporales cortas: Spark Structured Streaming en modo trigger-by-interval, o incluso polling agresivo sobre APIs REST con gestión de estado incremental. Es el punto de equilibrio más frecuente en pipelines de media intelligence: suficiente frescura para detectar tendencias emergentes, sin la complejidad del streaming puro.
Streaming real-time (<5 minutos o sub-minuto). Requiere brokers de mensajería, procesadores de eventos y una capa de almacenamiento que pueda absorber escrituras continuas. El valor es claro en sistemas de alerta temprana, pero el coste operativo es proporcional. Antes de entrar aquí, conviene asegurarse de que la fuente upstream (la API externa) puede sostener esa cadencia sin throttling.
El papel de las APIs externas en el diseño de latencia
Un error frecuente es diseñar la arquitectura de latencia sin modelar el comportamiento de las APIs upstream. Si el pipeline depende de APIs externas de datos —como las que expone FeedScale—, la latencia efectiva no solo depende del procesamiento interno: depende también de la frecuencia de actualización de esas APIs, sus límites de tasa y la granularidad de los endpoints de consulta.
Un pipeline near-real-time que consulta una API con ventana de actualización de diez minutos no puede entregar datos más frescos que esa ventana, independientemente de lo rápido que sea el procesamiento interno. Ignorar este factor lleva a arquitecturas que consumen recursos procesando datos que no han cambiado.
La integración correcta pasa por documentar explícitamente:
- La frecuencia de actualización de cada fuente externa.
- Los límites de tasa del proveedor y cómo afectan al polling máximo posible.
- La estrategia de backoff cuando la fuente no responde dentro del SLA esperado.
Con esa información, el SLO de latencia del pipeline se puede ajustar a lo que la cadena completa puede sostener, no solo a lo que el código interno puede procesar.
Cuando la arquitectura ya está construida: ajuste sin reconstruir
Si el pipeline ya existe y la latencia es un problema, la reconstrucción total rara vez es la primera opción. Hay palancas de ajuste más conservadoras:
- Dividir el pipeline en capas de velocidad diferente. Un patrón Lambda simplificado: una capa rápida que procesa señales recientes con menor profundidad analítica, y una capa lenta que reanaliza con mayor riqueza. Los consumidores eligen de qué capa leer según su tolerancia.
- Priorizar particiones de datos. No todos los datos del pipeline tienen la misma urgencia. Aplicar procesamiento prioritario a las fuentes más volátiles y diferir las menos críticas reduce la latencia percibida sin cambiar la infraestructura base.
- Cachés de resultados intermedios. En pipelines que reprocesen las mismas señales con frecuencia, cachear resultados intermedios puede reducir la latencia efectiva sin tocar la arquitectura de ingestión.
La latencia no es solo una métrica técnica. Es el contrato implícito entre la arquitectura y el valor que el sistema entrega. Formalizarla antes de construir es la diferencia entre un pipeline que escala y uno que se rediseña cada vez que el negocio cambia sus expectativas.