Por Andrew Tan
La diferencia entre casi en tiempo real y realmente en tiempo real, y por qué la brecha cuesta más de lo que piensas
El retraso de €4.7 millones
Un importante minorista europeo perdió €4.7 millones en Black Friday 2024. No porque su sitio web se cayera. No porque se quedaran sin stock. Porque su sistema de inventario "en tiempo real" estaba funcionando con un retraso de cuatro horas.
340,000 clientes realizaron pedidos de artículos que ya se habían agotado. El sistema mostraba disponibilidad. El almacén no tenía ninguno. Para cuando surgió la discrepancia, el daño ya estaba hecho. Reembolsos emitidos. Servicio al cliente abrumado. Reputación de la marca dañada. El análisis posterior reveló algo incómodo: el pipeline nunca fue diseñado para tiempo real. Fue diseñado para "casi en tiempo real", una distinción que sonaba técnica en las revisiones de arquitectura y resultó ser catastrófica en producción.
He escuchado versiones de esta historia docenas de veces. La brecha entre lo que promete "en tiempo real" y lo que la mayoría de los sistemas entregan es más amplia de lo que la mayoría de los equipos se dan cuenta. Y se está ampliando, no reduciendo, a medida que las expectativas de los clientes se aceleran.
Como una parada en boxes de Fórmula 1, el procesamiento de datos en tiempo real requiere precisión, coordinación e infraestructura adecuada.
Lo que realmente significa "en tiempo real" (y lo que no)
La industria ha enturbiado estas aguas. Tres categorías se confunden bajo la misma etiqueta.
Batch significa horas o días entre actualizaciones. Tu trabajo ETL nocturno. Tu informe semanal. Límites claros, ventanas predecibles, modos de falla bien entendidos.
Casi en tiempo real significa minutos entre actualizaciones. El sistema verifica cada cinco, quince, treinta minutos. La mayoría de los "paneles en tiempo real" caen aquí. Bueno para muchos casos de uso. No bueno para los que más importan.
En tiempo real significa segundos o subsegundos. El evento ocurre. El sistema lo sabe. La acción posterior se desencadena inmediatamente.
El minorista no tenía un problema de tiempo real. Tenían un sistema casi en tiempo real comercializado como tiempo real, y nadie cuestionó la diferencia hasta que les costó cuatro millones de euros.
Tres fuerzas que impulsan el cambio
El efecto Amazon. Los clientes esperan todo al instante. No porque hayan analizado los requisitos técnicos. Porque eso es lo que han sido entrenados para esperar. Un estudio de Shopify de 2022 de 12,000 consumidores encontró que el 73% espera actualizaciones de pago, inventario y envío en tiempo real. No "dentro de la hora". En tiempo real.
Las ventanas operativas se están reduciendo. La detección de fraudes después de la transacción no es detección. Es notificación. El dinero ya se ha ido. Las líneas de fabricación que esperan informes de calidad por lotes producen unidades defectuosas durante horas antes de que alguien se dé cuenta. El costo del retraso se compone más rápido de lo que la mayoría de las hojas de cálculo capturan.
Presión competitiva. Si tu competidor actualiza precios cada treinta segundos y tú actualizas cada seis horas, no estás compitiendo. Estás siendo espectador. Esto no es teórico. Plataformas de comercio electrónico, agregadores de viajes, servicios financieros. Las empresas que ganan en estos espacios hicieron de la infraestructura de datos en tiempo real una prioridad estratégica, no un lujo técnico.
La velocidad sin control es peligrosa. Los sistemas en tiempo real necesitan manejar la velocidad mientras mantienen la precisión y la fiabilidad.
La complejidad oculta
Pasar de batch a streaming es más difícil de lo que parece. La superficie parece simple: en lugar de esperar, reaccionar inmediatamente. Debajo, todo cambia.
Gestión de estado. Los trabajos por lotes procesan conjuntos de datos limitados. Conoces el tamaño de entrada cuando comienzas. El streaming procesa flujos ilimitados. Necesitas rastrear ventanas, manejar datos que llegan tarde, gestionar el estado a través de eventos que pueden llegar fuera de orden.
Procesamiento exactamente una vez. ¿Ejecutas un trabajo por lotes dos veces por accidente? Obtienes salida duplicada, lo arreglas y sigues adelante. ¿Ejecutas un pipeline de streaming dos veces? Cobras doble a los clientes, cuentas doble el inventario, notificas doble a los sistemas. La semántica importa de maneras que antes no importaban.
Contrapresión. ¿Qué pasa cuando tu fuente produce más rápido de lo que tu sumidero puede consumir? En batch, esto aparece como un trabajo lento. En streaming, aparece como mensajes perdidos, fallas en cascada o sistemas que simplemente dejan de responder.
Estos no son casos raros. Son el martes. Los equipos que subestiman esta complejidad terminan con pipelines que funcionan en demos y fallan en producción.
Cómo se ve el buen funcionamiento
Los sistemas bien arquitecturados en tiempo real comparten características.
Resiliencia por defecto. No añadida después. El sistema espera que los componentes fallen y continúa operando. Cortacircuitos. Degradación gradual. Colas limitadas que eliminan carga en lugar de colapsar.
Observabilidad. Necesitas ver qué está sucediendo dentro de un pipeline que procesa miles de eventos por segundo. Métricas que importan. Trazabilidad que sigue eventos a través del sistema. Alertas que se activan por síntomas, no solo por fallas de componentes.
Listo para el crecimiento. El sistema que maneja diez mil eventos por minuto debería manejar diez millones sin una reescritura. Escalado horizontal. Diseño consciente de particiones. Sin puntos únicos de contención.
Accesible. La integración de datos en tiempo real no debería requerir un doctorado en sistemas distribuidos. Las herramientas existen. La documentación es clara. Los conceptos son aprendibles. Los equipos deberían ser productivos en días, no en trimestres.
Este último punto importa más que los otros. Los equipos que tienen éxito con la infraestructura en tiempo real no son los que tienen la tecnología más sofisticada. Son los que la hicieron lo suficientemente accesible para que sus equipos existentes la operen.
La brecha de accesibilidad
Se está formando un mercado de dos niveles. Primer nivel: empresas con equipos dedicados a streaming, experiencia en Kafka, ingenieros de infraestructura que entienden el reequilibrio de particiones y la semántica exactamente una vez. Segundo nivel: todos los demás, atrapados con batch porque el tiempo real parece demasiado complejo para intentarlo.
Esto está al revés. La integración de datos en tiempo real debería ser tan accesible como el procesamiento por lotes. Mismo equipo. Mismo nivel de habilidad. Mismo tiempo de producción. La tecnología está ahí. Lo que falta es el empaquetado. Herramientas que manejan la complejidad para que los equipos no tengan que hacerlo.
En layline.io, estamos construyendo para el segundo nivel. Workflows unificados que manejan tanto batch como streaming con las mismas interfaces. Resiliencia y observabilidad integradas. Escalado que ocurre automáticamente. El objetivo no es hacer que el streaming sea simple. Es complejo, y pretender lo contrario no ayuda a nadie. El objetivo es hacerlo accesible.
Porque los minoristas, fabricantes y empresas de servicios financieros que necesitan datos en tiempo real ya tienen equipos inteligentes. No necesitan personas diferentes. Necesitan mejores herramientas.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresariales que maneja tanto cargas de trabajo por lotes como en tiempo real a escala.