Una cadena de döner con 4 sucursales en Izmir Alsancak está conectada simultáneamente a Getir Yemek, Trendyol GO y Yemeksepeti. En lugar de mantener tres menús, usan thMenu como master record; los decrementos de stock ocurren en un solo lugar y un fan-out vía webhook actualiza las tres plataformas.
Arquitectura master record
La columna products.stock_quantity en D1_MENU es la fuente canónica única. Al confirmar un pedido: UPDATE products SET stock_quantity = stock_quantity - 1 WHERE id = ? AND stock_quantity > 0. 0 filas afectadas = sin stock.
Al éxito, un evento va a Cloudflare Queue. Tres workers parchean en paralelo las APIs. Latencia media 340 ms.
Resolución de conflictos
Escenario: 5 lahmacun en stock. En el mismo segundo entran 5 pedidos desde tres plataformas. El UPDATE atómico serializa — el último encuentra 0 y es rechazado. Estado final 0, tres señales "agotado".
D1 no tiene row locks explícitos pero WHERE stock > 0 cumple el mismo rol. Cero ventas en exceso en 6 meses.
Reconciliación de derivas
Yemeksepeti tiene 30 s de delay, Trendyol es inmediato, Getir polea cada 5 s. Un cron horario compara las tres con el master.
- Yemeksepeti 5, Getir 3: master a 5, PATCH Getir
- Master 0, plataforma 2: PATCH 0 inmediato
- Deriva > 3: alerta Slack
FAQ
¿Hay que cargar el menú en cada plataforma manualmente? No, master record + fan-out automatizan todo.
¿Quién tiene prioridad en una race condition? FIFO por timestamp; el perdedor recibe 422.
¿El cron es manual? No, horario en Workers con alerta Slack.
¿Te resultó útil? Compártelo.
Artículos relacionados
¿Qué es un menú QR? La guía completa para restaurantes
Un menú QR permite a tus clientes acceder a tu carta al instante desde el móvil,…
Pasar del menú en papel al menú QR digital: guía paso a paso
¿Quieres adoptar los menús QR pero no sabes por dónde empezar? Esta guía cubre f…
Menús QR geolocalizados: servir distintos idiomas según la IP del visitante
Cómo un resort de 180 plazas en Antalya enruta el mismo QR a menús turcos, alema…