Event Sourcing não falha por ser complexo.
Falha por ser tratado como conceito ou ideologia.
Existe uma romantização perigosa em torno do Event Sourcing (ES). Em conferências, talks patrocinados e artigos superficiais, ele quase sempre aparece acompanhado do CQRS, e de um mantra repetido à exaustão: ”Consistência eventual”.
Para arquitetos de PowerPoint, essa frase soa libertadora.
Para quem opera em sistemas críticos como plataformas de adquirência ou sistemas com risco financeiro real, ela soa como irresponsabilidade técnica disfarçada de sofisticação.
A proposta original do Event Sourcing é elegante: persistir a intenção e a mudança, não apenas o estado final. Registrar o porquê, não apenas o resultado. O problema não está na ideia. Está no abismo que separa essa elegância conceitual da brutalidade operacional de um sistema que precisa processar milhares de transações por segundo, com SLA medido em milissegundos, rodando em produção sob carga real.
Quando tratado como um estilo arquitetural universal, Event Sourcing tende ao fracasso. Quando tratado como um padrão de persistência de alta performance, aplicado cirurgicamente a problemas de ciclo de vida curto, ele se torna um superpoder.
O hype da “arquitetura reativa”
A narrativa dominante afirma que sistemas modernos devem ser modelados “orientados a eventos” para desacoplar domínios e escalar organizações. O erro começa quando essa lógica é aplicada ignorando o essencial: o ciclo de vida do dado.
Sistemas de cadastro, como por exemplo clientes, produtos, contas e contratos, possuem ciclos de vida longos e indefinidos. Um cliente nasce e sofre mutações por anos, às vezes décadas. Aplicar Event Sourcing nesse contexto transforma uma consulta trivial de “informações do cliente” em uma reidratação custosa de milhares de eventos acumulados ao longo do tempo. O custo cognitivo e computacional cresce sem gerar valor proporcional. É como tentar pregar um parafuso utilizando um martelo.
Transações financeiras, por outro lado, possuem ciclos de vida curtos e finitos. Uma autorização de transação de um cartão de crédito por exemplo, nasce, é avaliada, aprovada ou negada, capturada, liquidada. O ciclo se fecha. Nesse contexto, a história importa mais do que o estado final.
O erro não está no Event Sourcing. O erro está em ignorar que arquitetura começa pelo ciclo de vida do dado, não pela estética do diagrama ou preferência.
É nesse ponto que frases de efeito como “consistência eventual” se tornam perigosas.
No processo de Autorização, no contexto de Adquirência, se o saldo não estiver consistente no exato milissegundo da decisão, não existe “eventual”. Existe prejuízo. A perda é real.
Onde a teoria sangra
A lousa aceita tudo. O runtime, não. Na segurança dos diagramas, o Event Sourcing é um fluxo elegante de intenções e fatos. No ambiente hostil da produção, ele é uma batalha constante contra a física do hardware. Quando a abstração desce para o metal, a complexidade deixa de ser um detalhe de implementação e cobra seu preço na moeda mais cara da engenharia: a latência.
O custo da reidratação e o pesadelo da abstração
A teoria é simples: carregar os eventos e reconstruir o estado atual.
A prática é brutal: o sistema tem 100 ms.
Implementações ingênuas, baseadas em Reflection genérica e serialização JSON padrão, transformam a elegância do padrão no maior gargalo da aplicação. Em ecossistemas gerenciados (.NET/Java), a abstração custa caro. O Garbage Collector não negocia com a pureza do código; ele pausa o mundo para limpar a sujeira que a abstração gerou.
Em ambientes críticos, Event Sourcing não falha por falta de elegância. Falha por excesso de abstração no caminho crítico.
Engenharia real exige abandonar o purismo e aceitar complexidade quando necessário: uso de compiled lambdas, estruturas mais próximas do hardware, serializadores binários como MessagePack e decisões conscientes para reduzir alocação e pressão de GC.
O Paradoxo do Código Mutável vs. Evento Imutável
Eventos são eternos. O código, não. O maior pesadelo operacional do ES surge 6 meses após o go-live, quando a regra de negócio muda e novas propriedades são adicionadas às classes de evento. O sistema precisa ler eventos gravados em 2024 usando classes compiladas em 2025.
Se a estratégia de versionamento não for desenhada no dia zero, o sistema quebra na desserialização. A solução não é alterar o evento passado (crime inafiançável em ES), mas implementar Upcasters, que são componentes intermediários que interceptam o evento antigo durante a leitura e o transformam, em memória, para a estrutura nova antes de entregá-lo ao domínio.
A ilusão da consistência eventual
Em adquirência, consistência eventual é uma meia-verdade. E meia-verdade em sistemas financeiros é inaceitável.
Modelos de leitura podem, sim, ser eventuais. Dashboards, extratos e relatórios toleram atraso. O modelo de escrita, não. O agregado responsável por autorizar ou negar uma transação precisa operar sobre o estado mais recente e de forma atômica.
O desafio não é “aceitar a eventualidade”. O desafio é desenhar fronteiras precisas e aplicar controle de concorrência com rigor suficiente para impedir que dois terminais gastem o mesmo saldo ao mesmo tempo.
A mecânica para isso não é mágica, é matemática com o Controle de Concorrência Otimista. Cada Agregado possui uma versão (um número sequencial). Ao tentar gravar um novo evento, o comando deve informar qual é a versão esperada (ExpectedVersion) do fluxo.
Se o Agregado estava na versão 10 quando foi lido, e ao tentar gravar a versão 11 o banco informa que a versão atual já é 12, significa que outro processo alterou o estado nesse ínterim. A operação falha, não por erro de sistema, mas por proteção de integridade. É assim que é garantido que dois terminais nunca gastem o mesmo saldo, sem a necessidade de locks pessimistas que matariam a performance do banco.
Em adquirência, consistência não é um espectro.
É um pré-requisito binário: ou existe, ou existe prejuízo.
A complexidade cognitiva e o fator humano
O maior risco do Event Sourcing raramente é técnico. É humano.
Um banco relacional é legível por qualquer profissional com SQL básico. Um Event Store, não. Ele exige contexto, ferramentas e maturidade.
Sem visualizações adequadas, sem disciplina conceitual e sem uma cultura sólida de engenharia, o sistema se transforma em uma caixa preta. A ausência de UPDATE e DELETE, substituídos por compensações explícitas, não é apenas uma mudança técnica. É uma mudança cultural profunda.
Event Sourcing não exige apenas novos padrões de código. Exige novos padrões mentais.
Event Sourcing como mecanismo de precisão
Despido do hype e tratado como padrão de persistência, Event Sourcing encontra seu lugar natural no caminho crítico de sistemas transacionais.
Append-only e performance de escrita.
Bancos relacionais sofrem com locks, contenção e fragmentação de índices sob alta concorrência de escrita. Event Sourcing opera em modo append-only, a operação de I/O mais simples e rápida disponível. Discos rígidos e SSDs performam ordens de grandeza melhor em escritas sequenciais do que em aleatórias. Enquanto um banco relacional luta contra Page Splits e fragmentação física de arquivo, o Event Store navega a favor da física do disco.
Auditoria e prova do passado
Sistemas CRUD sofrem de amnésia estrutural: conhecem o saldo atual, mas perdem a trilha que levou até ele. Logs de texto são frágeis, desacoplados da regra de negócio e frequentemente imprecisos.
Com Event Sourcing, a auditoria deixa de ser uma análise textual e torna-se uma ciência exata. Ao reidratar o agregado no estado preciso do milissegundo de uma transação, é possível reproduzir fielmente os efeitos da decisão tomada. Isso permite provar de forma determinística, e não apenas inferir, a razão exata de uma decisão.
“Eventos são fatos. Eles não devem ser reinterpretados.”.
O equilíbrio pragmático: sobrevivendo à produção
A teoria do Event Sourcing é elegante, mas a realidade de operação é brutal. Para que a arquitetura sobreviva fora do ambiente de desenvolvimento, abandonamos o purismo em favor de três mecanismos de defesa não negociáveis.
A Matemática dos Snapshots
A reidratação linear de eventos é uma sentença de morte para a latência. Um sistema não pode ficar mais lento à medida que envelhece. A estratégia de Snapshots deixa de ser uma otimização e vira um requisito funcional de performance na escala. Ao persistir snapshots do estado a cada N eventos, onde N é um limite fixo e controlado, a carga do agregado passa a ter custo de tempo constante O(1), limitado pela aplicação de no máximo N eventos, independentemente da idade ou do volume histórico do stream
Isolamento de Falhas nas Projeções:
A separação entre escrita e leitura não é apenas sobre performance, é sobre sobrevivência. O transacional opera exclusivamente no Event Store. Relatórios, dashboards e outros componentes analíticos vivem em ambientes segregados (ex: SQL ou Elastic), alimentados de forma assíncrona. Essa estratégia cria diferentes pontos de falha: se o relatório atrasar, gera-se um inconveniente operacional; se a transação atrasar, perde-se receita. O acoplamento temporal entre o "passar o cartão" e o "ver o extrato" é rompido deliberadamente.
Arquitetura não é sobre evitar a falha, é sobre escolher a consequência.
A Disciplina dos Bounded Contexts
O erro mais comum é tratar Event Sourcing como um martelo dourado para todo o sistema. A engenharia real exige persistência poliglota. O Event Sourcing reina soberano no ciclo de vida curto e transacional, mas é uma ferramenta terrível para dados cadastrais estáticos. Clientes, produtos e tabelas de domínio continuam residindo em bancos relacionais tradicionais. A complexidade do ES só se justifica quando o ganho em rastreabilidade, vazão e prova é imperativo para o negócio.
Síntese: O Custo da Verdade
Event Sourcing não serve para simplificar a engenharia; serve para blindar o negócio.
É uma troca consciente: pagar o preço da complexidade técnica para comprar certezas em um cenário que não admite aproximações. Sem a necessidade crítica de rastreabilidade, vazão e auditoria, essa complexidade se torna apenas dívida técnica antecipada.
Mas no coração de sistemas críticos, onde a latência é inimiga e o erro custa dinheiro, a imutabilidade deixa de ser um "estilo arquitetural". Ela se torna a única forma aceitável de verdade.
