Pedidos Multimodales: QR, Camarero y Telefono en una sola Mesa

Viernes por la noche en Eskisehir: cinco personas a la mesa. Dos piden por QR, dos a traves del POS del camarero, la quinta llama por telefono para una racion para llevar. Tres canales, una mesa, una cuenta — y 2.300 pedidos al mes caen limpios en una sola table_session.

Una sesion, varias fuentes

Cada mesa abre una table_session con TTL de 1 hora. QR, POS y telefono comparten el mismo session_token; el campo order_source traza el origen.

La conciliacion al cierre paso de 40–50 minutos a 3 minutos.

Escrituras atomicas

POSTs concurrentes con Idempotency-Key via crypto.randomUUID() y db.batch() atomico en D1.

• QR y POS escriben sin colision.
• El servidor impone el precio canonico.
• Shadowban se aplica por fuente.

Respuesta tecnica a "Unified Orders"

Un order_source enum, una FK table_session_id y tarjetas KDS coloreadas por fuente. Telefono azul, QR verde.

Bonus: los clientes mayores prefieren el camarero, captando un 18% de uso que el QR solo perderia.

FAQ

Como se adjunta un pedido telefonico a la sesion? El camarero elige el numero de mesa; reutiliza sesion abierta o crea una nueva.

Y si dos QR anaden lo mismo a la vez? Dos filas order_item, dos tarjetas KDS — intencional.

Que pasa al cumplir 1 hora de TTL? Las cuentas abiertas se conservan; el cron 04:00 UTC solo limpia sesiones cerradas.

¿Te resultó útil? Compártelo.