Event Sourcing em sistemas financeiros: quando vale o custo

Event sourcing promete um histórico imutável e auditável de tudo que aconteceu em um sistema. Em core banking, essa promessa é especialmente atraente — mas o padrão tem um custo real de complexidade que precisa ser justificado.

Onde o custo compensa

• Ledger contábil — a própria natureza de partida dobrada já é um log de eventos; formalizar isso como event sourcing é uma extensão natural.
• Trilhas de compliance — reguladores frequentemente pedem "reconstrua o que o cliente via na tela em uma data específica". Sem eventos, isso é arqueologia de logs; com eventos, é uma projeção.
• Conciliação com o Banco Central — divergências entre o que o SPI confirma e o que o core registrou são resolvidas comparando streams de eventos, não comparando snapshots de tabelas.

Onde normalmente não compensa

Cadastro de cliente, preferências de notificação, configurações de conta — dados que mudam por substituição, não por acumulação de fatos de negócio, raramente justificam o overhead de um event store dedicado.

Arquitetura de referência

Uma fila durável (como um broker baseado em log) como fonte de verdade dos eventos de domínio, com:

• Projeções materializadas para leitura (read models) reconstruídas de forma assíncrona.
• Replay controlado, usado tanto para corrigir bugs de projeção quanto para auditorias formais.
• Contratos de evento versionados desde o primeiro dia — o maior erro em sistemas de eventos financeiros é tratar o schema do evento como algo descartável.

Event sourcing bem aplicado transforma auditoria de um exercício doloroso em uma consulta.