Pos Em Banco De Dados

O que realmente acontece quando seu sistema de vendas conecta ao banco

A maior parte dos desenvolvedores que eu já vi entrando na área de ponta de venda (POS) com banco de dados começa fazendo a coisa errada. Cria tabelas genéricas, não pensa em concorrência, e aí quando o restaurante ou a loja começa a ter movimento real, o sistema trava. Eu levei uns dois anos pra aprender isso na prática, depois de ver três clientes meus perderem meia noite inteira corrigindo integridade referencial que ninguém havia pensado. Vamos direto. Um banco de dados para POS não é um banco de dados qualquer. Ele precisa lidar com operações simultâneas, rollback em caso de falha no pagamento, conciliação de caixa, e ainda respeitar regulamentações como a NF-e e o SPED. Se você tratar um POS como um CRUD any onde for, vai se dar mal.

pos em banco de dados: a estrutura que funciona

Achei que ia dar certo usando MySQL com InnoDB padrão. Errei feio. O problema é que InnoDB lida bem com transações isoladas, mas quando você tem dez caixas abertos ao mesmo tempo e cada um lança uma venda com troco, desconto, cupom e estorno no mesmo segundo, a bloqueação de linha vira pesadelo. Meu workaround foi partitionar por data de fechamento de caixa. Cada caixa abre com um ID de sessão que vira chave de partição. Assim, as vendas do caixa 03 não conflitam com as do caixa 07, mesmo que sejam executadas no mesmo instante. Isso reduziu os deadlocks de uma média de 40 por dia para zero, em três semanas de ajuste. As tabelas essenciais são: caixa_abertura, venda_item, pagamento, estorno, e conciliacao_financeira. Cada uma com índices compostos por caixa_id + created_at. Sem esse índice composto, a query de fechamento de caixa leva de 12 segundos para 4 minutos, dependendo do volume de dados acumulados.

Como modelar as tabelas sem errar

A tabela venda não pode ter apenas id, produto, quantidade e valor. Precisa ter, pelo menos, caixa_id, usuario_id, tipo_operacao (venda normal, troca, estorno parcial), status_pgto, e timestamp com precisão de milissegundo. Eu vi gente usando INT para caixa_id. Quando a rede cai e o caixa reinicia, o número vira ambiguidade e você não consegue conciliar depois. A tabela pagamento é onde a maioria dos erros acontece. Ela precisa ser imutável depois de gravada. Se o operador cancelar uma venda, não se apaga o registro de pagamento. Se cria um registro de estorno com tipo estorno e referência ao pagamento original. Isso é requisito da Receita Federal para auditoria, não opção. Um detalhe que ninguém conta: o campo valor_total deve ser DECIMAL(10,2), nunca FLOAT ou DOUBLE. Float tem problema de precisão em binário. Eu perdi R$ 0,37 em conciliação porque usei float. Demorei seis meses pra rastrear. Desde então, só decimal mesmo.

Transações e integridade na prática

Uma venda em POS envolve, pelo menos, três operações atômicas: baixa de estoque, lançamento financeiro, e emissão de cupom. Se uma delas falhar, todas devem voltar. Isso se chama transação ACID. Mas na prática, o banco pode aplicar o commit parcial se você não configurar o isolamento corretamente. O nível de isolamento REPEATABLE READ do InnoDB resolve 90% dos casos. Os outros 10% exigem lock explicito com SELECT FOR UPDATE na linha do estoque antes de decrementar. Eu aprendi isso depois de ter dois clientes vendendo o último item do estoque simultaneamente. Um ficou com estoque negativo. O sistema permitiu a venda. A conciliação não fechou. Outro problema comum: o timestamp. Use UTC em todos os registros. Nunca armazene horário local. Quando seu sistema atende cliente no Amazonas e outro em São Paulo no mesmo segundo, a conversão de fuso vira dor de cabeça. Eu migrei todo meu histórico de 18 meses de dados para UTC. Levou dois dias. Economizou quatro horas semanais de ajustes manuais.

Quando pos em banco de dados não é a melhor solução

Se seu movimento é baixo, menos de 50 vendas por dia, e você não precisa de NF-e ou SPED, um SQLite pode resolver. É mais simples, não precisa de servidor separado, e o backup é copiar um arquivo. Eu já vi small businesses usarem essa abordagem com sucesso por dois anos. Mas se você precisa de múltiplos caixas, integração com ERP, ou relatórios em tempo real, SQLite não aguenta. O locking é pessimista e bloqueia writes quando há reads simultâneos. Eu testei com 200 vendas por hora. O sistema travou em 47 minutos. Migrei para PostgreSQL com particionamento. Custou três dias de desenvolvimento. Funciona há 14 meses sem um único deadlock. PostgreSQL tem vantagens sobre MySQL para POS: native support para JSONB (útil para campos variáveis de produto), melhor performance em queries complexas de conciliação, e extension para uuid-ossp que elimina a necessidade de auto-increment em cenários distribuídos.

Backup e recuperação que funcionam

Backup não é copiar o diretório data. É fazer dump lógico com pg_dump ou mysqldump, incluindo constraints, índices, e stored procedures. Eu vi gente confiar em snapshot de disco. Quando o banco corrompeu, o snapshot também corrompeu. Perdi três dias de vendas. O backup diário deve rodar em horário de menor movimento, entre 3h e 5h da manhã. Isso geralmente significa redução de 95% nos conflitos de lock durante o backup. Teste a restauração semanalmente. Backup sem teste de restauração é ilusão de segurança. Um plano básico: backup completo semanal, incremental diário, e transaction log em tempo real. Isso reduz o RPO (Recovery Point Objective) para menos de 5 minutos. O RTO (Recovery Time Objective) fica em torno de 30 minutos, dependendo do volume de dados.

Monitoramento que evita surpresas

Não espere o sistema cair pra descobrir que algo está errado. Monitore wait events, lock escalation, e table bloat. No PostgreSQL, a view pg_stat_activity mostra sessões bloqueadas em tempo real. No MySQL, o performance schema faz algo similar. Eu configuro alertas para: lock wait timeout excedido, tabelas com mais de 20% de tuplas mortas, e conexões ativas acima de 80% do máximo. Esses três indicadores costumam dar um aviso de 24 a 48 horas antes de um problema crítico. Já me salvaram de quatro quedas em dois anos. O bloat de tabela é especialmente traiçoeiro em POS. Cada estorno ou correção gera tuplas mortas que não sãoadas automaticamente. O VACUUM do PostgreSQL resolve isso, mas se desligado ou mal configurado, a tabela cresce sem parar. Eu vejo crescimento de 15% ao mês em tabelas de venda sem vacuum adequado. Em seis meses, a performance cai 40%.