Vantagens e Desvantagens do Event Sourcing

A decisão de adotar Event Sourcing raramente é reversível a baixo custo, e por isso precisa ser tomada com o balanço completo na mesa. De um lado, o padrão entrega propriedades que nenhum mecanismo adicional sobre CRUD reproduz com a mesma solidez: auditoria inerente, depuração temporal, consultas históricas e integração baseada em fatos. De outro, cobra curva de aprendizado real, disciplina permanente de evolução de schema, desafios concretos de privacidade com o direito ao esquecimento e complexidade de consulta que exige projeções desde o primeiro dia. Este arquivo organiza os dois lados com critérios objetivos, para que a escolha seja uma decisão de engenharia com custos conhecidos, e não uma moda técnica descoberta tarde demais.

O que o padrão entrega de fato

As vantagens do Event Sourcing não são promessas genéricas, são propriedades derivadas diretamente do log imutável. Cada uma delas elimina uma classe inteira de problemas que sistemas tradicionais enfrentam com soluções paralelas.

• Auditoria natural e completa: todo fato tem autor, comando de origem, horário e posição na sequência; não existe mudança sem registro, e não existe registro sem mudança. Atender um regulador deixa de ser projeto e vira consulta.
• Depuração temporal: um bug reproduz-se executando o stream da entidade até o instante da falha, com o estado exato da época. Fim dos incidentes impossíveis de explicar porque o dado já foi sobrescrito.
• Consultas históricas: responder como o saldo estava em dezembro, ou qual catálogo o cliente viu no momento da compra, é uma leitura de log com corte, não uma arqueologia em backups.
• Correção sem edição de dados: regras erradas são corrigidas no código e as projeções são reconstruídas por replay; ninguém edita linha em produção.
• Integração por eventos: sistemas vizinhos consomem fatos de domínio já gravados, com histórico completo disponível para novos consumidores, sem ETL retroativo.
• Concorrência explícita: a versão esperada torna colisões de escrita detectáveis por construção, e o time deixa de conviver com perdas silenciosas de atualização.
• Testes determinísticos: cenários de teste são listas de eventos de entrada e saída, rápidos, sem banco e estáveis sob refatoração.
• Compliance por desenho: exigências como trilha imutável e retentativa de integridade deixam de ser projeto à parte, porque o log já as entrega.

Vale notar o efeito acumulado dessas propriedades. Isoladamente, cada uma tem equivalentes imperfeitos em sistemas CRUD, como triggers de auditoria e tabelas de histórico. O que o Event Sourcing muda é a origem: todas vêm da mesma estrutura, sem custo marginal adicional, e por isso não divergem entre si nem do dado real.

Os custos que precisam entrar no balanço

As desvantagens são tão concretas quanto as vantagens, e a maioria delas é permanente, não transitória. A lista a seguir reflete o que times em produção relatam com mais frequência.

• Curva de aprendizado real: o modelo mental de eventos, comandos, agregados e projeções é diferente do CRUD, e a produtividade do time cai visivelmente nos primeiros meses. Contratar e formar gente para manter o sistema custa mais.
• Evolução de schema permanente: eventos nunca mudam, e toda alteração de formato exige versionamento e upcasting. Esse custo não termina nunca, enquanto o sistema existir e evoluir.
• Complexidade de consulta: perguntas comuns de produto, como listar pedidos com filtro, exigem projeções desenhadas e mantidas. O banco de leitura gratuito do CRUD desaparece.
• Crescimento sem limite natural: o log só cresce, e o armazenamento precisa de política de retenção, arquivamento e custo previsto desde o início.
• Defasagem entre escrita e leitura: a consistência eventual muda a experiência do usuário e exige padrões de interface específicos.
• Infraestrutura e operação: subscriptions, checkpoints, reconstrução de projeções e monitoramento de lag são componentes novos que precisam de dono.
• Ferramental menos maduro: bibliotecas, documentação e profissionais experientes são mais raros do que no ecossistema CRUD dominante.
• Migração de saída difícil: uma vez o log como verdade, voltar a CRUD exige reconstrução de estado e reescrita de todo o caminho de escrita, decisão que precisa ser tratada como irreversível.
• Custos ocultos de suporte: atender cliente com consistência eventual pede scripts novos e mudança de expectativa, e a área de atendimento precisa ser treinada junto com o time técnico.

O direito ao esquecimento: LGPD e GDPR

O maior obstáculo conceitual do Event Sourcing frente à privacidade é óbvio: o padrão promete nunca apagar, e a legislação de proteção de dados dá ao titular o direito de ter dados pessoais eliminados. Não há solução única, mas existem três estratégias técnicas consolidadas que resolvem o conflito na prática.

A primeira é não gravar dados pessoais no log. O evento carrega uma referência, como titular-9f31, e os dados sensíveis vivem em um armazenamento apagável; o log registra o fato, não o dado. Essa é a solução mais simples e a mais recomendada quando o desenho ainda está aberto.

A segunda é crypto-shredding. Os payloads do titular são cifrados com uma chave exclusiva dele, e o exercício do direito é a destruição dessa chave; os eventos continuam no log, mas tornam-se ilegíveis de forma definitiva. Exige disciplina na escolha de bibliotecas e na gestão de chaves, e é a resposta padrão quando os dados já precisam estar nos eventos.

A terceira é combinar eventos de esquecimento com limpeza nas projeções. As visões de leitura, que são descartáveis por definição, excluem os dados do titular, e o log retém apenas o mínimo necessário a interesses legítimos documentados, como registros contábeis que a própria lei manda conservar. Cada caso exige análise jurídica específica, e a decisão arquitetônica precisa estar alinhada com o DPO antes da primeira linha de código.

// Crypto-shredding: cifrar o payload com chave exclusiva do titular
public class ProtecaoDeTitular {
    private final String titularId;
    private final Chaveiro chaves;      // chaves guardadas fora do log de eventos

    public byte[] proteger(byte[] payload) {
        // evento gravado com dados cifrados; sem a chave, é ruído permanente
        return Cifra.aes(chaves.chaveDo(titularId), payload);
    }

    // Exercício do direito ao esquecimento
    public void esquecer() {
        chaves.destruir(titularId);     // eventos permanecem, mas ficam ilegíveis
        publicar(new DadosDoTitularRemovidos(titularId));   // projeções e índices limpam o titular
    }
}

O mecanismo mantém a promessa de imutabilidade intacta: nada é apagado do log, e ainda assim o dado pessoal se torna irrecuperável, inclusive em backups antigos, porque nenhum deles carrega a chave. O ponto frágil está fora do código, na governança das chaves; por isso o roteiro de destruição precisa ser auditável e testado como qualquer operação crítica.

Comparação com a persistência tradicional

Critérios objetivos de adoção

O padrão se paga quando o valor do histórico é alto e as exigências de conformidade são estruturais. Os sinais favoráveis são claros.

• Domínio regulado ou litigioso, onde provar o que aconteceu e quando é requisito de negócio, como banking, saúde e mercados financeiros.
• Necessidade real de consultas temporais frequentes, e não apenas curiosidade ocasional, como reconstruir posições históricas ou disputas de cliente.
• Integração ampla por eventos já prevista, onde o log vira canal natural para outros sistemas.
• Domínio com regras de concorrência delicadas, onde perder uma atualização em silêncio é inaceitável.
• Complexidade de negócio que já pede DDD, com agregados e linguagem onipresente, onde o custo marginal do padrão cai.

Os sinais contrários são igualmente objetivos: time iniciante em domínio já complexo, produto em descoberta com modelo mudando a cada semana, sistema majoritariamente de leitura sobre dados estáveis, e ausência de exigência de auditoria ou histórico. Nesses casos, CRUD bem feito com tabelas de eventos pontuais entrega quase tudo por uma fração do custo, e o Event Sourcing entra depois, se o cenário mudar.

Erros comuns na avaliação

• Decidir pela novidade técnica sem identificar qual vantagem específica o produto precisa; o resultado é pagar todos os custos e colher nenhuma propriedade.
• Subestimar a evolução de schema, imaginando que eventos não mudam; eles mudam, e o mecanismo de upcasting precisa existir desde o primeiro release.
• Tratar o direito ao esquecimento como problema futuro; a estratégia de privacidade precisa estar no desenho, porque refazer o log depois é inviável.
• Aplicar o padrão no sistema inteiro quando apenas um subdomínio, como contas e pagamentos, concentra as exigências de auditoria.
• Ignorar o custo de formação, medindo a adoção apenas em linhas de código e não em meses de produtividade do time.
• Comparar apenas a persistência, esquecendo que o padrão chega acompanhado de projeções, subscriptions e consistência eventual, que são o grosso da operação.

Sintomas de adoção mal avaliada

Quando a decisão é tomada sem o balanço completo, os sintomas aparecem em produção com padrões reconhecíveis e mitigações conhecidas.

Como pesar na prática

A avaliação honesta compara custos por cenário, e não por slides. Uma técnica efetiva é listar as três perguntas de negócio mais valiosas que o sistema precisa responder sobre o passado, estimar o custo de respondê-las com CRUD, incluindo auditorias manuais, tabelas de histórico e risco de erro, e estimar o custo de respondê-las com Event Sourcing, incluindo projeções e operação. Quando a soma do lado CRUD passa a soma do lado ES, a decisão se escreve sozinha, com números que o negócio entende.

Outra técnica é a adoção por subdomínio, começando pela parte onde a auditoria é obrigação, como pagamentos e saldos, e mantendo CRUD nos subdomínios de suporte, como cadastros simples e configurações. Essa fronteira reduz o custo de formação, isola o investimento e dá ao time um território para amadurecer antes de expandir. O erro oposto, aplicar tudo de uma vez, transforma o projeto de arquitetura em um programa de meses, com risco concentrado e retorno adiado.

Um terceiro critério, frequentemente decisivo, é a maturidade operacional do time. O padrão exige dono para lag de projeção, runbooks testados para reconstrução e disciplina de versionamento em cada release; sem essa infraestrutura humana, a primeira crise de dados encontra o sistema desarmado. Times que já operam mensageria com idempotência e monitoramento de fila transferem essa experiência diretamente, e a adoção custa menos; times que nunca administraram consumo assíncrono precisam construir essa musculatura antes, e o plano de adoção deve incluir essa etapa explicitamente.