Once mil eventos por minuto.
Mismo stack — escala a diez mil.
Dodo Pizza — franquicia internacional con más de 800 restaurantes implementados en 17 países — enfrentaba desafíos críticos para gestionar operaciones en tiempo real. Implementamos una arquitectura moderna de datos con procesamiento de eventos en tiempo real basada en Microsoft Databricks y Apache Kafka: captura de eventos streaming con taxonomía completa, arquitectura medallion Bronze → Silver → Gold en Databricks, procesamiento distribuido con Apache Spark, Apache Superset como capa de visualización conectada directamente, y persistencia en Delta Lake. Hoy el stack soporta crecimiento de 800 a 1000+ restaurantes sin redesigns fundamentales.
El caso, en cuatro frases.
Para los que llegaron desde LinkedIn y solo tienen 30 segundos. Si quieres profundidad, sigue scrolleando.
Operación de 800 restaurantes sin visibilidad en tiempo real.
Cocina, entrega, POS, inventario — cada sistema emitía sus datos, pero la lectura cross-operacional era post-mortem. Cuando se descubría un problema, el cliente ya lo había sufrido.
Construimos sobre Kafka + Databricks + Spark + Delta Lake.
Eventos streaming con taxonomía completa (cocina · entrega · POS · inventario · IoT). Procesamiento Spark Structured Streaming. Medallion clara. Persistencia en Delta Lake.
Apache Superset como ventana directa al lakehouse.
Sin BI propietario costoso. Superset conectado directo a Databricks · dashboards operativos para gerentes · panel ejecutivo agregado · queries en segundos.
Escala probada: de 800 a 1 000+ restaurantes sin redesign.
La arquitectura horizontal soporta crecimiento del negocio sin fricción técnica. 100 restaurantes nuevos en 2025 absorbidos sin sprint de ingeniería.
Dodo Pizza · Franquicia internacional llegó con un problema medible.
- 01
Falta de visibilidad real-time
Gerentes de local veían lo que pasó ayer a las 9 AM del día siguiente. En operaciones QSR donde un sábado se gana o se pierde el mes, esto es ceguera total.
+24h delay - 02
Eventos dispersos sin taxonomía común
Cocina llamaba al evento `order_ready`, delivery lo llamaba `pickup_available`, POS lo llamaba `closed_order`. Tres palabras, tres equipos, una realidad imposible de medir.
0 taxonomía - 03
Imposibilidad de reaccionar a tiempo
Cuando un local se quedaba sin queso a las 18:00 del viernes, el corporate se enteraba el lunes. Pérdida ya ocurrida, imposible mitigar.
reactivo · post-pérdida - 04
Análisis solo retrospectivo
Los reportes de fin de mes generaban hallazgos «interesantes» que no podían convertirse en acción — la oportunidad ya había pasado. La analítica era arqueología, no operación.
arqueología · no operación - 05
Infraestructura insostenible al crecer
Cada vez que se abría un país nuevo, ingeniería pasaba meses adaptando scripts. Crecer de 600 a 700 restaurantes tomó 8 meses de trabajo no creativo.
crecer = pena ingeniería - 06
Sin separación raw / processed / analytical
Mismas tablas mezclaban datos crudos, procesados y agregados. Una vez que algo se mezclaba mal, recomputar todo tomaba días.
tablas-frankenstein - 07
BI propietario caro y lento
Las queries del dashboard ejecutivo tardaban minutos. Las licencias del BI vendor consumían USD 200k/año. El equipo lo abría una vez al mes.
BI caro · sub-usado
Lo que construimos.
No reemplazamos lo que ya funcionaba. Construimos capas finas que comunicaron sistemas ciegos entre sí.
Kitchen manager dashboard · Superset en tablet
Gerente de cocina en tablet. Vista en tiempo real de pedidos en cola, tiempo medio de preparación, stock crítico, predicción de pico próxima hora. Refresh cada 5 segundos.
Regional exec panel · Superset desktop
Vista regional: top 5 países, top 10 restaurantes, drill-down por país → región → restaurante. KPIs unificados desde gold layer.
Predictive ML · Databricks notebooks
Modelos predictivos (LightGBM + Prophet) corren sobre la Gold layer · forecast de pedidos por restaurante × hora × día siguiente. Output a otra tabla Gold para activar alertas y rutas.
Alerting engine · Slack/Telegram local
Reglas declarativas + ML detection. Si stock < 20% en SKU crítico → notificación al gerente. Si tiempo de cocina > 4 min × 5 pedidos seguidos → alerta a supervisor.
Stack y capas.
stack: Microsoft Databricks · Apache Kafka · Apache Spark · Delta Lake · Apache Superset · Azure Data Lake Storage · MLflow · Kafka Connect · MQTT
Ingesta · streaming
Procesamiento
Almacenamiento · Delta Lake
Superficies
Los números.
Medidos por el equipo del cliente, no por nosotros. Comparativa: baseline previo al go-live.
«El stack que abrió 800 restaurantes va a abrir 1 000. Sin reescribir nada.»
Lo que aprendimos — y aplicamos en el siguiente caso.
Medallion no es jerga — es disciplina arquitectónica.
La tentación es saltar Bronze e ingerir directo en Silver «porque ya viene limpio». No viene limpio. Y cuando un schema cambia, sin Bronze no tienes a dónde volver. La Bronze es el seguro contra errores futuros que aún no conoces.
Delta Lake es time travel, no solo storage.
Debugging de incidentes es trivial cuando puedes pedir «muéstrame esa tabla como era hace 3 horas». Sin Delta, debugging es arqueología sobre logs. Con Delta, es queries SQL.
El stack que escala sin redesign vale más que el stack óptimo.
Podríamos haber optimizado para 800 restaurantes y reescrito para 1000. Pero el costo del re-escribir cada vez que crecemos es lo que mata operaciones a escala. El medallion funciona igual con 8 restaurantes que con 8000.
¿Te suena familiar? Hablemos.
No vendemos software de plantilla. Empezamos siempre con una auditoría gratis de 4 semanas: nos sentamos con tu equipo, mapeamos sistemas y dolores, y entregamos un PDF con 3–5 quick wins concretas.