Pedidos Multimodais: QR, Garcom e Telefone na mesma Mesa

Sexta a noite em Eskisehir: cinco pessoas a mesa. Duas pedem por QR, duas pelo POS do garcom, a quinta liga para um pedido para viagem. Tres canais, uma mesa, uma conta — e 2.300 pedidos por mes caem limpos em uma unica table_session.

Uma sessao, varias fontes

Cada mesa abre uma table_session com TTL de 1 hora. QR, POS e telefone compartilham o mesmo session_token; o campo order_source rastreia a origem.

A conciliacao caiu de 40–50 minutos para 3 minutos.

Escrita atomica

POSTs concorrentes resolvidos por Idempotency-Key via crypto.randomUUID() e db.batch() atomico em D1.

• QR e POS sem colisao.
• Servidor impoe preco canonico.
• Shadowban por fonte.

Resposta tecnica a "Unified Orders"

Um order_source enum, FK table_session_id compartilhada e cartoes KDS coloridos por origem. Telefone azul, QR verde.

Clientes idosos preferem o garcom, capturando 18% de uso que o QR sozinho perderia.

FAQ

Como um pedido por telefone entra na sessao certa? O garcom escolhe a mesa; reutiliza sessao aberta ou abre nova.

Dois QR adicionam o mesmo item ao mesmo tempo? Duas linhas order_item, dois cartoes KDS — proposital.

E se o TTL de 1h expirar? Contas abertas sao preservadas; o cron 04:00 UTC limpa apenas sessoes fechadas.

Achou útil? Compartilhe.