Existe uma regra não escrita em times de produto: ninguém quer trabalhar no módulo financeiro. É o lugar onde bugs têm consequências reais, onde requisitos mudam por decreto do governo, e onde um centavo de diferença entre o que o sistema mostra e o que o banco registra pode virar um incidente.

Trabalhei durante anos desenvolvendo e mantendo módulos financeiros. Aprendi mais sobre software robusto nesse contexto do que em qualquer outro.

Dinheiro não tolera aproximação

O primeiro aprendizado, doloroso, foi sobre tipos de dados. Usar float para representar valores monetários é um bug esperando o momento certo para aparecer. Ponto flutuante tem erros de representação que, somados ao longo de milhares de transações, geram diferenças que nenhum relatório fecha.

A solução padrão — armazenar valores em centavos como inteiros, ou usar tipos DECIMAL/NUMERIC com precisão explícita no banco — parece burocrática até o dia que você evita um fechamento contábil errado graças a ela.

Em sistemas financeiros, a representação dos dados é uma decisão de arquitetura, não de implementação.

Auditoria não é opcional

Toda operação financeira precisa de rastro. Não só o estado atual — o histórico completo de como se chegou até ele.

Um pagamento cancelado, um desconto aplicado retroativamente, uma nota fiscal emitida com valor errado: em todos esses casos, você precisa ser capaz de reconstruir exatamente o que aconteceu, em qual ordem, por quem e com qual justificativa.

Implementamos tabelas de auditoria com imutabilidade garantida por trigger: nenhuma linha podia ser alterada, apenas novas linhas podiam ser inseridas registrando cada transição de estado. O custo de storage era irrelevante comparado ao custo de não ter essa rastreabilidade numa auditoria fiscal.

Concorrência e o problema do duplo débito

Em sistemas de cobrança, a concorrência é um inimigo silencioso. Dois processos tentando processar o mesmo pagamento simultaneamente podem gerar cobranças duplicadas — um dos cenários mais difíceis de explicar para um cliente.

A solução passa por transações de banco com isolamento correto, locks pessimistas ou otimistas dependendo do contexto, e idempotência em toda operação que pode ser retentada: processar duas vezes uma operação idempotente deve ter o mesmo resultado que processar uma vez.

Parece óbvio no papel. Na prática, é onde a maioria dos sistemas financeiros amadores falha.

Regras fiscais mudam — o código não pode quebrar

Uma das maiores fontes de dívida técnica em módulos financeiros é hardcode de regras fiscais. Alíquota de imposto no código, regras de isenção em condicionais espalhadas, cálculos de nota fiscal acoplados ao fluxo de pagamento.

Quando a legislação muda — e ela muda, frequentemente — o trabalho de atualizar um sistema assim é proporcional ao quanto ele foi mal projetado.

A solução é tratar regras fiscais como dados, não como código. Configuráveis, versionadas, com data de vigência. O motor de cálculo permanece estável; as regras que ele aplica mudam conforme a realidade tributária.

O que módulos financeiros ensinam sobre qualidade

Nenhum outro domínio torna os custos da qualidade tão tangíveis quanto o financeiro. Um bug aqui não é um ticket de suporte — é uma disputa comercial, uma auditoria, um processo judicial.

Isso muda a cultura do time. Code review mais criterioso, testes com casos extremos reais, homologação com contadores antes de ir para produção. O nível de cuidado que um módulo financeiro exige é o nível de cuidado que todos os sistemas deveriam ter — mas raramente têm.