Antes de comenzar
Inspeccionarás un flujo de eventos estable, formularás una hipótesis sobre backlog y particiones, provocarás un pico de tráfico y la caída de un consumidor, y observarás cómo reacciona (y se recupera) el sistema. Luego consultarás con SQL real (DuckDB-Wasm) los eventos que el streaming ya procesó.
Producirás una evidencia de aprendizaje con tu hipótesis, tu operación del streaming y tu decisión de capacidad justificada. Tiempo orientativo: 30–40 minutos.
¿Cómo puede NexoRetail mantener un pipeline de eventos continuo y estable cuando los eventos llegan más rápido de lo que se pueden procesar?
- Contexto
- NexoRetail 360 opera una sala de control de streaming: productores de ventas, clics y sensores IoT envían eventos sin pausa a un broker con particiones, y consumidores los procesan en paralelo.
- Problema
- Cuando la producción supera la capacidad de consumo, el backlog crece — y un consumidor lento o caído reduce aún más esa capacidad, sin que el sistema "falle" de forma visible; solo acumula retraso.
- Misión
- Mantener el backlog bajo control ante picos de tráfico y fallos de consumidores, sin sobre-aprovisionar capacidad que no se necesita. No existe una única respuesta correcta: cada combinación de particiones y consumidores implica un compromiso distinto.
- Decisión esperada
- Elegir cuántos consumidores y particiones usar para absorber un pico sin acumular backlog permanente, y justificar esa elección con evidencia observada.
Objetivos de la sesión
- Diferenciar procesamiento por lotes (Semana 4) de streaming continuo.
- Relacionar productores, particiones y consumidores con el paralelismo real disponible.
- Explicar causalmente el backpressure: cuándo aparece y por qué crece el backlog.
- Reaccionar ante un consumidor lento o caído y verificar la recuperación.
Streaming, backpressure y analítica en tiempo real
Un pipeline de streaming mueve eventos desde productores hacia un broker con particiones, donde esperan a que los consumidores los procesen. Cuando la producción supera el throughput de los consumidores, el backlog crece: aparece backpressure y la latencia percibida sube. Los eventos ya consumidos alimentan, en micro-lotes, un motor analítico real con una política de retención/ventana que limita cuántos conserva.
Importante: en este laboratorio, el comportamiento de productores, broker y consumidores (incluyendo backlog, latencia y los incidentes) es una simulación que corre en esta pestaña del navegador — no es Kafka, Flink ni ningún broker real. En cambio, la sección "Analítica en tiempo real" ejecuta SQL real con DuckDB-Wasm sobre los eventos que el streaming simulado ya procesó: esa parte sí es un motor de base de datos genuino, no una simulación.
Ver los 10 conceptos en detalle qué son, por qué importan, qué observarás
- Evento
- Qué es: un registro individual (una venta, un clic, una lectura IoT) con marca de tiempo, tipo y datos propios. Por qué importa: es la unidad mínima que atraviesa todo el pipeline. Observarás: cada evento aparece como un punto en la cola del broker mientras espera ser consumido.
- Productor
- Qué es: el proceso que genera y envía eventos al broker sin pausa. Por qué importa: su tasa (productores × tasa por productor) define cuánta presión recibe el sistema. Observarás: sube "Productores" o "Tasa por productor" y crecerá la producción total por segundo.
- Broker
- Qué es: el intermediario (el "topic" con sus particiones) donde los eventos esperan a ser consumidos. Por qué importa: acumula el backlog cuando la producción supera la capacidad de consumo. Observarás: la caja "Broker / topic" muestra cuántos eventos están en cola en este momento.
- Consumidor
- Qué es: un proceso que lee y procesa eventos del broker. Por qué importa: su capacidad total, limitada por el número de particiones, determina cuánto se puede procesar en paralelo. Observarás: si subes "Consumidores" por encima de "Particiones del topic", los consumidores extra quedan ociosos.
- Throughput
- Qué es: eventos procesados por segundo, en un instante dado. Por qué importa: comparado con la producción, indica si el sistema drena o acumula backlog. Observarás: el indicador "Throughput" en la telemetría del streaming.
- Backlog
- Qué es: los eventos que ya llegaron al broker pero todavía no fueron consumidos. Por qué importa: es el síntoma más visible de que la producción supera la capacidad. Observarás: el indicador "Backlog" crece durante un pico de tráfico o un incidente de consumidor.
- Backpressure
- Qué es: la condición en la que la producción excede sostenidamente la capacidad de consumo. Por qué importa: sin intervención, el backlog y la latencia crecen sin límite. Observarás: el texto de "Telemetría del streaming" cambia a "Backpressure" cuando esto ocurre.
- Latencia
- Qué es: el tiempo estimado que un evento espera en el broker antes de ser procesado. Por qué importa: crece con el backlog, y es lo que el negocio percibe como "lentitud". Observarás: "Latencia estimada" sube junto con el backlog.
- Micro-lote
- Qué es: el grupo de eventos ya consumidos que se inserta de una sola vez en el motor analítico DuckDB-Wasm, en vez de insertarlos uno por uno. Por qué importa: reduce el overhead de escritura sin perder frescura del análisis. Observarás: el contador "Micro-lotes analizados" en la sección de analítica.
- Retención / ventana
- Qué es: la política que conserva solo los eventos más recientes en el motor analítico (máx. 4000), descartando los más antiguos. Por qué importa: evita que una sesión larga agote la memoria del navegador. Observarás: "Eventos retenidos" nunca supera ese máximo, aunque "Eventos ingeridos" siga creciendo.
Pasos del laboratorio
- Inspecciona el escenario normal (particiones y consumidores por defecto).
- Formula tu hipótesis sobre el backlog y los consumidores ociosos.
- Inicia el flujo estable y observa cómo se comporta.
- Provoca un pico de tráfico.
- Observa cómo crecen el backlog y la latencia.
- Fuerza un consumidor lento o caído.
- Fuerza o espera la recuperación de capacidad.
- Inspecciona agregados analíticos reales (DuckDB-Wasm) sobre los eventos ya consumidos.
- Elige una estrategia operativa de particiones, consumidores y capacidad.
- Justifica tu decisión con la evidencia observada.
Hipótesis
Una hipótesis es tu predicción antes de observar los resultados. Regístrala ahora: una vez bloqueada, no podrás cambiarla, solo reformularla después de ver el resultado.
Completa las dos preguntas y pulsa «Registrar hipótesis y comenzar» para desbloquear el streaming.
Mientras operas el streaming
- Producción vs. capacidad — cuántos eventos entran por segundo frente a cuántos se pueden procesar.
- Backlog — eventos pendientes acumulados en el broker.
- Latencia — tiempo estimado que un evento espera en cola.
- Throughput — eventos procesados por segundo en este instante.
- Eventos retenidos en la analítica en tiempo real (DuckDB-Wasm).
Flujo productor → broker → consumidor
Escenarios operativos
Cada incidente se revierte solo tras unos segundos, pero puedes forzar la recuperación manualmente.
Antes de forzar la recuperación: ¿cómo esperas que reaccionen el backlog y la latencia una vez que el consumidor vuelva a su capacidad normal?
Telemetría del streaming
Inicia el flujo y modifica la capacidad de los consumidores para ver un resumen basado en el estado real.
Aquí verás la relación entre tu configuración (particiones, consumidores, capacidad) y el backlog/latencia observados.
Aquí verás qué implicaría este resultado para operar el streaming real de NexoRetail.
Alertas y eventos recientes
Analítica en tiempo real (DuckDB-Wasm)
El streaming (broker, consumidores, backpressure) sigue siendo una simulación de este mismo navegador. Esta sección analiza con SQL real, en micro-lotes, los eventos que el streaming ya consumió. DuckDB no reemplaza a Kafka/Flink/Spark Streaming ni decide el backpressure — solo consulta eventos ya procesados.
Los eventos analizados aquí nunca salen de este navegador ni se envían a ningún servidor.
Inicializando motor local de datos…
Consulta ejecutada localmente mediante DuckDB-Wasm — datos reales, no inventados por JavaScript.
¿Cuántos consumidores y particiones recomendarías para absorber un pico sin acumular backlog permanente?
Cierre conceptual
Lo que descubriste: cómo el desbalance entre producción y capacidad de consumo genera backlog y backpressure, cómo un incidente de consumidor lo agrava, y cómo se recupera un pipeline de streaming.
Concepto para recordar: las particiones limitan el paralelismo real disponible — agregar consumidores más allá del número de particiones no acelera nada, solo los deja ociosos.
Conexión con la próxima semana: en la Semana 6 llevarás esta arquitectura a la nube y añadirás controles de seguridad sobre confidencialidad, integridad y disponibilidad.
Genera tu evidencia
Esta evidencia resume tu hipótesis, tu operación del streaming y tu decisión de capacidad. Puedes utilizarla para discusión, entrega o reflexión posterior.
Continuidad curricular
Antes: en la Semana 4 procesamos datos ya recolectados, en lotes.
Después: en la Semana 6 llevaremos esta arquitectura a la nube y añadiremos controles de seguridad sobre confidencialidad, integridad y disponibilidad.