O que «funciona offline» significa mesmo num POS de restaurante

Todos os POS na nuvem dizem que funcionam offline. Muito poucos explicam o que essa frase cobre, e a distância entre a promessa e o comportamento descobre-se na pior noite do ano.

Offline é um problema de fila, não de ecrã

Qualquer aplicação consegue guardar a carta em cache e desenhar um ecrã sem ligação. Essa é a metade fácil. A difícil é o que acontece às vinte encomendas, quatro reembolsos e um turno fechado criados enquanto a linha esteve em baixo.

Não são ecrãs. São factos de que dependem os números de outras pessoas: o stock, a cozinha, os livros, a gaveta. Trazê-los de volta pela ordem certa, exatamente uma vez, é todo o problema de engenharia.

O que a caixa tem de continuar a fazer

Sem internet, um ponto de venda ainda tem de:

• Abrir um turno e registar o fundo de maneio.
• Mostrar a carta completa, com preços, modificadores, tamanhos e menus.
• Tirar pedidos, retê-los, dividir contas, aplicar descontos e códigos promocionais.
• Cobrar em dinheiro e imprimir o talão numa impressora ligada localmente.
• Anular e reembolsar com as mesmas regras de aprovação.
• Continuar a contar a gaveta para o fecho bater certo.

Isso é um restaurante a funcionar. Nada nesta lista precisa de um servidor para ser verdade.

O que sinceramente não pode funcionar

A honestidade aqui é uma funcionalidade, não uma fraqueza:

• Cartão e pagamentos online. Uma autorização precisa do gateway. Cobra em dinheiro, ou com cartão quando a linha voltar.
• Vistas entre lojas em direto. O stock de outra filial é um facto que vive no servidor.
• Tudo o que um segundo dispositivo tenha de ver de imediato. Um ecrã de cozinha na mesma rede local ainda pode ser servido; um telemóvel em dados móveis não.

Um sistema que afirme que tudo isto funciona offline está errado, ou está a redefinir a palavra.

Como a recuperação é tornada segura

Quando a ligação volta, o dispositivo não se limita a reenviar. Cada ação foi escrita localmente como um registo imutável no momento em que aconteceu, com:

O servidor guarda-as com uma chave única em (deviceId, clientActionId). Se a mesma ação chegar duas vezes — wifi instável, reinício da app, uma repetição impaciente — a segunda é reconhecida e devolve-se o resultado original, em vez de criar uma segunda encomenda. Os pagamentos trazem uma chave de idempotência pelo mesmo motivo: uma repetição não pode cobrar duas vezes.

As repetições vão-se espaçando em vez de martelar a ligação, e o que continua a falhar depois do limite fica numa fila morta que um responsável vê e resolve, em vez de desaparecer em silêncio.

Quando duas caixas se contradizem

É a pergunta que vale a pena fazer a qualquer fornecedor. Duas caixas offline. Ambas vendem as últimas cinco doses do prato do dia. Ambas voltam ao mesmo tempo.

Não há resposta mágica — as doses não existem. O que importa é que o sistema seja determinístico e lho diga:

• Stock que ficaria negativo é recusado com um erro acionável, não aceite em silêncio.
• O estado da encomenda só avança por transições válidas: uma comanda «servida» não reabre.
• Um pagamento superior ao total é recusado.
• O estado das mesas assume a versão do servidor, porque duas pessoas não podem ocupar a mesa 6.

Ainda assim terá de oferecer um prato. Mas saberá no momento do conflito, em vez de encontrar uma linha de stock negativa três semanas depois.

O teste de um minuto

Antes de assinar com alguém, faça isto na demonstração: ponha o tablet em modo de voo, tire quatro pedidos, reembolse um, feche o turno e volte a ligar. Depois veja três ecrãs — stock, histórico de cozinha e vendas do dia — e confirme que as quatro encomendas lá estão, uma vez cada, pela ordem certa, com o reembolso estornado.

Esse teste demora um minuto e diz mais do que qualquer lista de funcionalidades.