A lo largo del módulo hemos tratado los eventos como unidades discretas: un pedido se crea, un pago se confirma. Pero hay una clase de problemas en los que los eventos llegan de forma continua y a gran velocidad —clics de usuarios, lecturas de sensores IoT, transacciones de tarjeta, líneas de log— y el valor está en procesarlos según fluyen, sin esperar a acumularlos. Esto es el streaming de datos en tiempo real: tratar los datos como un flujo infinito (unbounded) sobre el que aplicamos transformaciones, agregaciones y detección de patrones en cuestión de milisegundos.

El streaming es la base de casos de uso como la detección de fraude al instante, los cuadros de mando en vivo, las recomendaciones en tiempo real o la monitorización de sistemas. En esta lección entenderás la diferencia fundamental entre procesamiento por lotes (batch) y por flujos (streaming), el papel de las ventanas temporales, y cómo Kafka Streams nos permite implementar todo esto con código relativamente sencillo.

1. Batch vs Streaming: la diferencia fundamental
2. Conceptos del procesamiento de flujos
3. Ventanas (windows): agrupar el tiempo
4. Kafka Streams: procesamiento sobre Kafka
5. Ejemplo: detección de fraude por ventana
6. Casos de uso reales
7. Errores comunes y consejos
8. Ejercicios y soluciones
9. Conclusión

El procesamiento por lotes (batch) opera sobre un conjunto de datos finito y completo (por ejemplo, "todas las ventas de ayer") en un momento programado. El procesamiento por flujos (streaming) opera sobre un flujo infinito de eventos a medida que llegan.

La frase clave: en batch tienes todos los datos antes de empezar; en streaming nunca los tienes todos, porque siempre puede llegar uno más. Esto obliga a razonar de otra forma, especialmente con el tiempo.

Antes de programar, fijemos el vocabulario:

• Stream: secuencia infinita de eventos ordenados (aproximadamente) en el tiempo.
• Transformaciones sin estado (stateless): procesan cada evento de forma independiente. Ejemplos: filter (descartar), map (transformar).
• Transformaciones con estado (stateful): necesitan recordar información de eventos anteriores. Ejemplos: contar, sumar, agregar por clave. Requieren un almacén de estado (state store).
• Tiempo del evento (event time) vs tiempo de procesamiento (processing time):
  • Event time: cuándo ocurrió el evento (marca en el propio mensaje).
  • Processing time: cuándo lo procesa el sistema.
  • Pueden diferir mucho (un evento de un móvil sin cobertura puede llegar minutos tarde). El procesamiento serio se basa en event time.
• Datos tardíos (late data): eventos que llegan después de lo esperado. El sistema debe decidir si los incorpora o los descarta.

Como el flujo es infinito, no podemos "sumar todo". En su lugar, agrupamos los eventos en ventanas temporales y calculamos sobre cada ventana. Hay tres tipos principales:

Ejemplo: para detectar fraude buscamos "más de 3 pagos en 1 minuto desde la misma tarjeta". Eso es una agregación con estado sobre una ventana de 1 minuto agrupada por tarjeta.

Kafka Streams es una librería Java que consume de topics de Kafka, procesa los datos (filtrado, agregación, ventanas, joins) y escribe los resultados en otros topics. No necesita un clúster aparte: es código que despliegas como una aplicación normal y que escala añadiendo instancias.

Conceptos de su API:

• KStream: representa un flujo de eventos (cada registro es un hecho independiente).
• KTable: representa una tabla de estado (cada clave tiene su último valor; los nuevos registros actualizan).
• State store: almacén local (respaldado en Kafka) donde se guardan las agregaciones con estado, tolerante a fallos.

• application.id es crítico: identifica la aplicación y nombra sus topics internos y state stores. Dos instancias con el mismo application.id forman un grupo y se reparten el trabajo.
• processing.guarantee: exactly_once_v2 activa el procesamiento exactly-once dentro de Kafka (entre topics), apoyándose en transacciones.

Detectemos tarjetas con más de 3 pagos en una ventana de 1 minuto:

Explicación paso a paso:

1. builder.stream("pagos") crea un KStream que lee cada pago del topic de entrada.
2. groupBy reagrupa por tarjetaId: ahora los eventos de la misma tarjeta comparten clave y se procesan juntos. Es la base de cualquier agregación con estado.
3. windowedBy(TimeWindows.ofSize... 1 minuto) define ventanas tumbling de un minuto. withNoGrace significa que no esperamos datos tardíos.
4. count(...) mantiene, en un state store tolerante a fallos, cuántos pagos lleva cada tarjeta en la ventana actual.
5. toStream() convierte la KTable de conteos en un flujo de cambios para poder seguir procesando.
6. filter(... conteo > 3) deja pasar solo las combinaciones tarjeta-ventana que superan el umbral de fraude.
7. map construye una AlertaFraude y to("alertas-fraude") la publica en el topic de salida, donde otro servicio podrá bloquear la tarjeta o avisar al cliente.

El resultado es un detector de fraude que reacciona en tiempo real, sin lotes nocturnos.

• Detección de fraude: patrones anómalos de transacciones al instante (como el ejemplo).
• Monitorización y alertas: detectar caídas de servicio o picos de errores en los logs en vivo.
• Cuadros de mando en tiempo real: ventas por minuto, usuarios activos ahora mismo.
• Recomendaciones: ajustar sugerencias según la navegación actual del usuario.
• IoT y telemetría: agregar lecturas de miles de sensores y detectar umbrales (temperatura, vibración).
• Enriquecimiento de eventos: unir (join) un flujo de pedidos con una tabla de clientes para añadir datos al vuelo.

• Confundir event time con processing time. Si agregas por processing time, un evento retrasado cae en la ventana equivocada y los resultados son incorrectos. Basa las ventanas en el tiempo del evento siempre que el orden importe.
• Ignorar los datos tardíos. Decide explícitamente tu política: periodo de gracia, descarte o reproceso. No decidir es decidir mal.
• Olvidar que el estado crece. Las agregaciones con estado consumen memoria/disco. Usa ventanas con retención acotada y limpia el estado obsoleto.
• Esperar "exactly-once" de extremo a extremo. Kafka Streams lo garantiza entre topics de Kafka, pero al escribir en sistemas externos vuelves a necesitar idempotencia (lección 05-02).
• Usar streaming cuando bastaba un batch. Si la latencia de horas es aceptable, un batch es más simple y barato. El streaming añade complejidad operativa.
• Consejo: empieza con transformaciones sin estado (filter, map); introduce estado y ventanas solo cuando el caso de uso lo exija.

1. Para cada caso, indica si usarías batch o streaming y por qué: (a) informe contable de cierre mensual; (b) alerta cuando un sensor supera 80 °C; (c) cálculo nocturno de comisiones; (d) contador de usuarios conectados en directo.
2. Quieres calcular una "media móvil de temperatura de los últimos 10 minutos, actualizada cada 2 minutos". ¿Qué tipo de ventana usarías y por qué?
3. Explica con tus palabras la diferencia entre KStream y KTable y pon un ejemplo de dato adecuado para cada uno.

1. (a) Batch: datos finitos del mes, sin urgencia. (b) Streaming: requiere reacción inmediata. (c) Batch: proceso programado nocturno sobre datos completos. (d) Streaming: métrica en vivo que cambia continuamente.
2. Una ventana hopping/sliding (deslizante) de tamaño 10 minutos con un salto (hop) de 2 minutos. Es deslizante porque las ventanas se solapan: cada 2 minutos se emite un nuevo resultado que cubre los últimos 10 minutos, que es justo lo que pide una media móvil.
3. Un KStream modela un flujo de hechos independientes (cada registro es un evento que se suma a los anteriores), por ejemplo cada pago o cada clic. Un KTable modela un estado por clave donde cada nuevo registro actualiza el valor anterior de esa clave, por ejemplo el saldo actual de cada cuenta o el último precio de cada producto.

El streaming de datos trata los eventos como un flujo infinito y los procesa según llegan, logrando latencias de milisegundos frente a las horas del batch. Aprendimos a razonar sobre el tiempo (event time vs processing time), a agrupar eventos en ventanas (tumbling, deslizantes y de sesión) y a implementar agregaciones con estado en Kafka Streams mediante un detector de fraude real. También vimos cuándo conviene streaming y cuándo basta un batch más sencillo.

Con esta lección cerramos el Módulo 5: Arquitecturas Dirigidas por Eventos y Mensajería. Has recorrido el camino completo: desde los fundamentos de los eventos y su mensajería asíncrona, pasando por el almacenamiento con Event Sourcing y CQRS, la coordinación de transacciones distribuidas con el patrón Saga, hasta el procesamiento de flujos en tiempo real. Estos patrones constituyen la columna vertebral de los sistemas distribuidos modernos y te preparan para diseñar arquitecturas escalables, resilientes y reactivas.