Reto de ingeniería
Operas la sala de control del streaming de NexoRetail 360. Productores de ventas, clics y sensores IoT envían eventos sin pausa a un broker con particiones; consumidores los procesan en paralelo. Tu trabajo es mantener el backlog bajo control ante picos de tráfico y fallos de consumidores, sin sobre-aprovisionar capacidad que no se necesita.
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.
1 · Hipótesis
Completa las dos preguntas y pulsa «Registrar hipótesis y comenzar» para desbloquear el streaming.
3 · Flujo productor → broker → consumidor
4 · Escenarios operativos
Cada incidente se revierte solo tras unos segundos, pero puedes forzar la recuperación manualmente.
5 · Telemetría del streaming
6 · Alertas y eventos recientes
7 · 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.
8 · Decisión de ingeniería
9 · Evidencia de aprendizaje
Continuidad curricular
Antes: en la Semana 4 procesamos datos ya recolectados, en lotes.
Después: ya operamos datos en movimiento. En la Semana 6 llevaremos esta arquitectura a la nube y añadiremos controles de seguridad sobre confidencialidad, integridad y disponibilidad.