Na Yooga, os terminais POS PRECISAM funcionar offline. Restaurante nao pode parar de tirar pedido porque o WiFi caiu. Entao o terminal tem banco local, processa transacao localmente e sincroniza com a nuvem quando tem internet. Parece simples ne? NAO EH. Principalmente quando envolve dinheiro de verdade. O desafio central eh resolucao de conflito. Terminal A vende a ultima picanha enquanto ta offline. Terminal B, tambem offline, vende a mesma ultima picanha. As duas transacoes sao validas localmente. Quando sincronizam, tu tem um conflito: duas vendas pro mesmo item. Num app de chat tu mergeia as duas mensagens e foda-se. Num sistema POS tu acabou de vender estoque que nao existe. Alguem vai ficar sem picanha. A gente explorou CRDTs no comeco. Conflict-free Replicated Data Types sao LINDOS na teoria. Cada terminal mantem o proprio estado, operacoes sao comutativas e associativas, merge eh automatico. Pra coisa tipo metadado de pedido, nota de cliente e mudanca de config, CRDT funciona muito bem. A gente usa Last-Writer-Wins pra maioria das configs e Grow-Only Set pros logs de auditoria. Mas CRDT desmorona pra dado de estoque e financeiro. Um counter CRDT rastreia incrementos e decrementos de multiplos nos, mas pode ficar negativo. Em estoque, negativo significa que tu vendeu o que nao tem. Em conciliacao financeira, negativo significa que teus livros tao errados. Pra esses dominios tu PRECISA de coordenacao -- e coordenacao significa estar online, o que mata o proposito do offline-first. Nossa solucao eh hibrida. Dado nao critico usa CRDT e sincroniza automatico. Dado de estoque e financeiro usa abordagem otimista local-first com reconciliacao server-side. O terminal registra a venda localmente com status "pendente_sync." Quando volta online, manda a transacao pro servidor. O servidor valida contra o estado atual. Se o estoque ta disponivel, confirma. Se nao, dispara fluxo de reconciliacao que envolve o gerente do restaurante. O protocolo de sync usa vector clock pra ordenacao. Cada terminal mantem um relogio logico que incrementa a cada operacao local. Na hora de sincronizar, o terminal manda o relogio e o servidor compara com o ultimo estado conhecido. Operacoes sao replayadas em ordem causal. Isso eh importante porque "adicionar item ao pedido" precisa acontecer ANTES de "aplicar desconto ao pedido" mesmo se chegarem fora de ordem. Batching eh critico pra performance. Restaurante lotado gera centenas de operacoes por hora por terminal. Sincronizar uma por uma ia destruir a rede e o servidor. A gente agrupa operacoes em chunks de 50 ou janelas de 30 segundos, o que vier primeiro. O batch eh comprimido, assinado com a chave do terminal e enviado como payload unico. Consistencia eventual funciona pra 95% das operacoes. Atualizacao de cardapio, atribuicao de mesa, escala de funcionario -- tudo isso pode ser eventualmente consistente e ninguem nota 30 segundos de delay. Mas confirmacao de PAGAMENTO precisa ser fortemente consistente. Quando o cliente paga, o terminal manda o evento de pagamento com requisito de confirmacao sincrona. Se nao consegue alcancar o servidor, enfileira o pagamento e marca como "confirmacao_pendente." O cupom sai com uma observacao. Eh um tradeoff de UX mas eh melhor que a alternativa de processar pagamento no escuro. Esse sistema ta rodando ha mais de um ano. Taxa de conflito abaixo de 0.3%. A maioria dos conflitos eh de estoque e resolve automatico porque o restaurante tinha mais estoque do que o sistema mostrava. O resto vai pra um dashboard onde o gerente resolve na mao. Nao eh perfeito, mas funciona em escala e funciona quando o WiFi inevitavelmente morre no rush de sabado a noite.