Hay una frase que se repite en casi todas las reuniones de tecnología con alguna aspiración: “Necesitamos los datos en tiempo real.”
Dicho así, suena a madurez. Suena a que la empresa está lista para el siguiente nivel. Suena, sobre todo, a que quien lo pide sabe de lo que está hablando.
En la mayoría de los casos, no saben. Y tampoco lo necesitan.
Como Business Engineer, mi trabajo es separar los problemas técnicos reales de la ansiedad operativa disfrazada de requerimiento tecnológico. Y el “tiempo real” es, quizás, el caso más frecuente de los dos.
¿Qué significa realmente “tiempo real”?
Antes de hablar de costos, es importante alinear el vocabulario. En la industria de datos, la latencia (el retraso entre que ocurre un evento y que lo puedes ver) se distribuye más o menos así:
| Modelo | Latencia típica | Nombre técnico |
|---|---|---|
| El dato aparece al instante | < 1 segundo | Stream Processing (Real Time) |
| El dato se actualiza cada minutos | 1 - 60 minutos | Near Real Time / Micro-batch |
| El dato se procesa en tandas | Horas o días | Batch Processing |
| El dato llega en un informe del día anterior | ~24 horas | Batch diario |
Cuando un gerente dice “quiero los datos en tiempo real”, generalmente quiere decir que no quiere esperar 3 días para que alguien le envíe un Excel por correo. Y tiene razón en eso. Pero la solución a ese problema es un batch diario automatizado, no un sistema de streaming.
Confundir ambos no es solo un error técnico. Es un error de presupuesto.
El costo exponencial de reducir la latencia
Aquí está el argumento que más me gusta presentar en reuniones, porque es matemáticamente honesto:
Reducir la latencia no tiene un costo lineal. Tiene un costo exponencial.
Pasar de recibir un informe una vez a la semana a recibirlo una vez al día es un cambio de arquitectura relativamente simple. Un Cron Job que se ejecuta a las 8:00 AM, consulta la base de datos y envía el correo. Costo marginal: casi cero.
Pasar de ese informe diario a un dashboard que se actualiza cada hora requiere una arquitectura algo más compleja: consultas programadas más frecuentes, posiblemente una capa de caché. Costo: moderado, pero manejable.
Pasar de eso a un sistema que procesa eventos y actualiza el estado en menos de un segundo requiere una infraestructura completamente distinta: Apache Kafka, Flink o Spark Streaming, bases de datos optimizadas para escrituras de alta frecuencia, equipos especializados para mantenerlo. Costo: órdenes de magnitud superior.
Importante (La pregunta correcta)
No es “¿queremos tiempo real?”. Es “¿cuánto vale para el negocio saber esto con 1 segundo de diferencia versus 24 horas?”. Si no hay una respuesta concreta en pesos, probablemente la respuesta es que no lo necesitan.
Batch Processing: El arte de la robustez
El procesamiento por lotes tiene mala fama injustificada. Se percibe como algo “anticuado”, como si fuera la solución de los que no saben hacer las cosas bien.
Es exactamente lo contrario.
Un sistema de Batch bien diseñado es predecible, auditable y robusto. Si falla, falla de forma ruidosa y en un momento conocido. Puedes reiniciarlo, puedes depurarlo, puedes saber exactamente en qué punto del proceso se rompió. Un sistema de streaming fallando en producción es uno de los tipos de incendios más difíciles de apagar en toda la ingeniería de datos.
Para el 99% de las PYMEs, la operación diaria se ve así:
- El gerente llega a las 8:30 AM.
- Toma un café.
- Revisa cómo cerró el día anterior.
- Toma decisiones para el día de hoy.
En ningún punto de ese flujo se necesita saber lo que pasó hace 800 milisegundos. Se necesita saber lo que pasó ayer, de forma clara, confiable y sin errores.
El caso del informe que se envía a mano
En nuestra operación, los informes diarios se envían por correo antes de las 9:00 AM. Y aquí viene la parte que puede parecer contraintuitiva: los envía una persona, no un sistema automático.
No tenemos ninguna limitación técnica que nos impida generar todos los informes con un cron job a las 8:59 AM y que se envíen solos. Podríamos hacerlo hoy. Pero no lo hacemos, y hay una razón operativa detrás de esa decisión que va más allá de la pereza o la falta de tiempo.
Cuando alguien se toma el tiempo de enviar el informe, estamos seguros de que alguien lo vio.
Un cron job que dispara un correo a las 9:00 AM exactas no tiene ojos. No sabe si el informe de hoy muestra un RUT mal validado que duplicó una cifra. No sabe si hubo un error de digitación donde una coma se leyó como miles y el total de ingresos parece el triple de lo habitual. El sistema no sabe, y tampoco le importa: ejecuta y envía.
La persona que prepara el informe, en cambio, puede notar esa inconsistencia. Puede detenerlo, corroborar el dato y enviarlo con una nota aclaratoria, o después de corregir el error en la fuente.
Intuición (El error de ingreso silencioso)
Un dato incorrecto puede tener muchos padres: una máquina que registra el sensor con un decimal desplazado, un operario que ingresa “1.200” cuando quiso decir “1,200” (¿son mil doscientos o un punto dos?), o un RUT que pasó la validación de formato pero no es real. La automatización ciega propaga estos errores a la velocidad de la luz. Un par de ojos humanos los detiene en seco.
La trampa psicológica de la “primera hora”
Hay otro argumento que suele pasarse por alto cuando se diseñan estos flujos, y es puramente humano.
Si automatizamos el envío del informe a las 8:00 AM en punto, implícitamente le estamos diciendo al encargado del dato que su tarea tiene una deadline de 8:00 AM. Que debe estar en su puesto, con la pantalla encendida, antes de esa hora, en competencia con el reloj.
Eso genera un falso sentido de urgencia que no tiene ningún fundamento en la realidad del negocio.
Un informe con datos de ayer que llega a las 8:45 AM en lugar de las 8:00 AM no cambia ninguna decisión. El café del gerente sigue igual de caliente. Pero el encargado del dato, si entra a las 8:05 AM y el correo ya salió automáticamente, perdió 40 minutos de revisión que podrían haber detectado una inconsistencia.
Al quitarle esa presión artificial de la “primera hora”, le damos el tiempo adecuado para hacer bien su trabajo: revisar, contrastar, y enviar un dato en el que todos podemos confiar.
¿Cuándo SÍ tiene sentido el tiempo real?
No quiero que este artículo suene como una defensa absolutista del batch. El tiempo real existe porque hay casos donde es genuinamente necesario:
- Transacciones financieras: La aprobación de un pago con tarjeta no puede esperar 24 horas. El fraude se detecta en milisegundos o no se detecta.
- Sistemas de control industrial: Si una máquina está a punto de sobrecalentarse, el sensor que la detiene no puede esperar al informe de mañana.
- Plataformas de e-commerce con alta concurrencia: El stock disponible debe ser preciso para que dos personas no compren el último producto al mismo tiempo.
- Dashboards de operaciones críticas en el momento del evento: Un Centro de Mando de emergencias, una operación de bolsa.
Nota lo que tienen en común: la latencia tiene consecuencias físicas o financieras que ocurren en segundos. Si omites un dato, alguien se quema, pierde dinero o el sistema se rompe en ese instante.
Si tu caso de uso no entra en esa categoría, probablemente estás pagando el precio del tiempo real para comprar algo que nunca va a usar.
La arquitectura correcta para una PYME madura
Para la mayoría de las operaciones que manejo, la arquitectura ideal se ve así:
[Fuentes de datos] ↓ (ingreso continuo durante el día)[Base de datos operacional (PostgreSQL)] ↓ (Cron Job nocturno - 02:00 AM)[Procesamiento y consolidación de datos] ↓ (Cron Job mañana - 08:30 AM)[Generación de informes] ↓[Revisión humana del encargado del dato] ↓[Envío del informe consolidado]El dato entra durante el día de forma continua. A las 2:00 AM, cuando nadie está usando el sistema, un proceso nocturno lo consolida, valida y prepara. A las 8:30 AM, los informes están listos para que el encargado los revise y envíe.
Esta arquitectura tiene cero costos de streaming, es predecible, es auditable y le da a un ser humano la oportunidad de ser la última línea de defensa antes de que un error llegue a la bandeja de entrada del gerente.
Resumen (El principio rector)
La madurez tecnológica no se mide por la velocidad de tus datos. Se mide por la confianza que tienes en ellos. Un dato de ayer que es 100% confiable vale más que un dato de ahora mismo que podría tener un error de ingreso que nadie revisó.
Conclusión
La próxima vez que alguien en una reunión proponga “implementar tiempo real”, hagan esta pregunta antes de aprobar el presupuesto: ¿Qué decisión de negocio cambia si sabemos este dato con 1 segundo de diferencia versus 1 hora?
Si hay una respuesta concreta, inviertan. Si la respuesta es silencio o un vago “para ser más ágiles”, probablemente lo que necesitan es un Cron Job bien configurado, un encargado del dato que entienda sus números y la cultura operativa para confiar en el proceso.
El tiempo real no es un indicador de madurez. Es una herramienta. Y como toda herramienta, su valor depende de si la estás usando para el problema correcto.