Vários garçons, uma mesa: resolução de conflitos no pedido

Num banquete de 1200 covers em Antalya Belek, quatro garçons adicionam pratos simultaneamente à mesma mesa redonda de 20 pessoas. O clássico "last-write-wins" sobrescreve silenciosamente 14 itens. Aqui está o caminho que pusemos em produção: optimistic locking, 409 Conflict e o padrão de retry.

Por que last-write-wins não basta

Um UPDATE orders SET items = ? WHERE id = ? guarda só o último commit. 4 POSTs em 200ms e a cozinha vê apenas 6 pratos de 20.

Solução: cada linha tem uma coluna version. O cliente lê ao abrir e devolve ao gravar; o servidor confere atomicamente.

Optimistic locking com versionamento

Adicione version INTEGER e updated_at. PATCH:

• Cliente: { items, expected_version: 7 }.
• Servidor: UPDATE ... WHERE id = ? AND version = 7.
• 0 linhas → 409 Conflict + estado atual.

409 Conflict + merge no cliente

Sem auto-retry. O cliente mostra o pedido atualizado, destaca mudanças e pede confirmação. Em Belek, os conflitos percebidos caíram de 0,4 % para 0 %.

Um log append-only order_events permite auditoria detalhada.

FAQ

Por que não SELECT FOR UPDATE? Serializa garçons e reduz throughput.

Funciona no D1? Sim, UPDATE atômico em INTEGER é seguro.

E offline? Fila local + expected_version; merge ao reconectar.

Achou útil? Compartilhe.