Datos en tiempo real: cuándo aportan valor al negocio

Cuando alguien pide datos en tiempo real, parece que acaba de concretar un requisito. Sin embargo, todavía falta la parte que permite decidir si merece la pena: qué va a hacer con esa información mientras conserve su utilidad. Detectar un pedido atascado antes de que el cliente lo cancele y refrescar una gráfica que se comentará el lunes pueden compartir tecnología, pero responden a necesidades muy distintas.

Conviene detenernos en esa conversación previa, porque es donde la velocidad deja de ser un adjetivo atractivo y empieza a tener consecuencias. Si llegar antes permite intervenir, habrá que defender la inversión; si nadie puede explicar qué cambia, conviene entender la necesidad antes de comprometer una arquitectura que después alguien tendrá que mantener. El valor de la frescura depende de la decisión que todavía estamos a tiempo de tomar.

¿Cuándo necesitamos datos en tiempo real?

Cuando disponer del dato antes cambia una decisión que todavía podemos ejecutar. El requisito debe unir el momento límite de esa decisión, la frescura necesaria y la capacidad de respuesta; una pantalla rápida no demuestra que la información sea reciente.

Uber: cuando unos segundos sí forman parte del producto

Hay negocios donde esta relación resulta muy concreta. En Real-time Data Infrastructure at Uber, publicado en 2021, sus ingenieros describen necesidades de frescura de segundos y, para determinados usos, un requisito de latencia de consulta inferior a un segundo en el percentil 99. Esto último significa que el umbral debe cubrir al menos el 99 % de las consultas, no solo que la consulta media responda deprisa. Son requisitos descritos para aquellos sistemas, no una medición actual de todo Uber.

El trabajo vincula esas exigencias a situaciones reconocibles: ajustar precios según oferta y demanda o servir información a los restaurantes de Uber Eats. También explica una renuncia: preprocesar los datos del gestor de restaurantes reduce la latencia, pero limita la flexibilidad de las consultas. La rapidez tiene una finalidad y una contrapartida; el estudio no establece cuánto ganaría cualquier otra empresa por imitarla.

De ese caso podemos extraer un criterio más útil que una lista de herramientas: relacionar la rapidez con la necesidad que la justifica. Una empresa de distribución, por ejemplo, podría necesitar avisar de una incidencia antes de cargar el camión y, a la vez, preparar las compras del día siguiente con una actualización mucho menos frecuente. Es un escenario hipotético, pero sirve para trasladar la pregunta: ¿en qué momento deja de ser útil una información para cada consumidor?

Una pantalla rápida puede mostrar datos antiguos

Para responder hay que separar dos cosas que se mezclan con facilidad: la antigüedad de la información y lo que tarda en aparecer en pantalla. Un dashboard puede responder en medio segundo porque consulta un resultado preparado durante la noche; la experiencia de navegación será buena, aunque la decisión se esté tomando con datos de ayer. También puede ocurrir lo contrario: disponer de eventos recientes y tardar demasiado en convertirlos en una respuesta útil.

Uber ya describía en su artículo de ingeniería de octubre de 2020 esa separación entre frescura de segundos y consultas inferiores a un segundo al combinar Pinot y Presto. El mismo sistema admitía datos preparados por procesos por lotes. Es un caso documentado por el propio equipo, no una comparación independiente entre productos, y muestra por qué «consulta en tiempo real» no basta para describir cuándo ocurrió lo que estamos viendo.

Snowflake permite concretarlo desde otro ángulo. Su documentación de Dynamic Tables establece un objetivo mínimo de retraso de 60 segundos y aclara que ese objetivo no es una garantía ni un intervalo fijo de ejecución. Se mide respecto a las tablas base del flujo: por tanto, no incluye necesariamente toda la demora previa desde el hecho original. Prometer al negocio «un minuto» a partir de ese ajuste, sin medir el recorrido completo, sería confundir una configuración con el servicio recibido.

La frescura debe medirse donde se toma la decisión. Además del tiempo de procesamiento, cuentan los retrasos de origen, la disponibilidad del resultado y cualquier espera hasta que lo ve su consumidor. Si solo conocemos una de esas piezas, todavía no podemos asegurar cuánto tarda la información en ser utilizable.

El precio de actuar con una foto provisional

Conocer antes lo ocurrido también puede significar conocerlo incompleto. Volvamos al almacén imaginario: han entrado los pedidos, pero una de las fuentes envía las anulaciones más tarde. El número visible cambiará cuando lleguen esos eventos, aunque el procesamiento haya funcionado correctamente. Para intervenir antes de la salida del camión quizá merezca la pena aceptar esa provisionalidad; para comparar semanas cerradas, seguramente necesitaremos un criterio más estable.

Esta tensión aparece en la operación real. El artículo de Uber de 2020 explica que incorporaban conjuntos de datos depurados por lotes para sustituir datos inconsistentes de la vía en tiempo real y mejorar la exactitud del análisis. Lo interesante es que la rapidez inicial convivía con una corrección posterior. No implica que todo sistema deba construirse igual, pero sí cuestiona la idea de que recibir antes un dato equivale a tener antes su versión definitiva.

Por eso, indicar que una cifra es provisional y hasta qué momento incorpora información forma parte del producto. Si el lector desconoce que faltan cancelaciones, puede interpretar una revisión como un fallo y perder confianza en un sistema que está haciendo lo previsto. Un número sin contexto temporal obliga al usuario a adivinar demasiado.

La organización también introduce latencia

Después del dato viene la respuesta. Una alerta puede llegar en segundos y quedarse esperando horas si nadie tiene responsabilidad o capacidad para atenderla; mejorar el procesamiento reducirá una parte pequeña de la demora total. Cuando discutimos una exigencia de frescura, también estamos decidiendo quién actúa, en qué horario y qué ocurre durante una incidencia.

Esto no elimina el valor de capturar eventos pronto para investigarlos después, ni el de observar rápidamente el efecto de un cambio de producto. Son usos legítimos, aunque no produzcan una intervención inmediata. Lo que exige es describir el beneficio con precisión, porque conservar información, explorar un problema y detener una operación necesitan compromisos diferentes.

Tampoco existe una regla universal que convierta menos latencia en más coste. La carga, el diseño y los recursos disponibles pueden favorecer un procesamiento continuo o uno por lotes. Para valorar ambas opciones, necesitamos incluir en la comparación el mantenimiento y las oportunidades perdidas al llegar tarde: recortar infraestructura mientras dejamos escapar una decisión valiosa puede salir bastante caro.

Modelo de la ventana útil

Podemos ordenar la conversación con el modelo de la ventana útil: decisión → ventana → frescura → completitud → acción. Es una síntesis propia de este análisis, no una fórmula universal para elegir tecnología.

Decisión: Qué resultado puede cambiar al conocer el dato.
Ventana: Hasta cuándo sigue siendo posible intervenir.
Frescura: Qué antigüedad máxima admite la información en el punto de uso.
Completitud: Qué ausencias o revisiones toleramos al decidir antes.
Acción: Quién puede actuar y qué tiempo necesita para hacerlo.

En el almacén del ejemplo, un aviso recibido antes de cargar el camión tiene utilidad si alguien puede reasignar el pedido. Si solo llega antes al dashboard, hemos ganado velocidad de presentación, pero todavía no sabemos si ganamos capacidad de intervención. El modelo ayuda a señalar qué compromiso falta; no calcula por sí mismo la arquitectura más barata.

Frescura ≠ latencia de consulta. La primera describe la antigüedad del dato disponible; la segunda, cuánto tarda en responder una consulta. Rapidez ≠ completitud. Un resultado temprano puede ser provisional.

Un compromiso que se pueda explicar

En el ejemplo del almacén, «necesitamos conocer las incidencias antes de la salida para poder reasignar pedidos» permite discutir un servicio concreto. El margen depende de la operación, y las excepciones importan tanto como la situación normal. A partir de ahí se puede valorar qué mejora aporta reducir la demora y qué otra capacidad habría que desarrollar para aprovecharla.

Esa preocupación enlaza con el riesgo de construir antes de comprender la necesidad. Cuando la conversación empieza y termina en una característica técnica, corremos el riesgo de entregar exactamente lo solicitado y dejar intacto el problema.

Podemos defender una exigencia muy ambiciosa si la decisión la necesita, incluso cuando resulte incómoda para el equipo técnico. También hay razones para aceptar una espera cuando la información siga siendo útil después. La madurez está en conocer esa diferencia y poder sostenerla con evidencia, en lugar de tratar cualquier demora como un defecto.