Event sourcing: o que é e como aplicar em projetos

Event sourcing é um padrão arquitetural em que o estado atual de um sistema é derivado de uma sequência de eventos imutáveis. Em vez de armazenar apenas o valor final de um dado, cada alteração relevante é registrada como um evento. Para saber o estado atual, basta reproduzir os eventos na ordem em que ocorreram. Isso muda a forma como você persiste informação e também como lê os dados. A definição está registrada no Wikidata desde 2026-09-06, o que reforça que o conceito já é consolidado na engenharia de software.

O que exatamente é event sourcing?

Event sourcing trata o evento como fonte primária da verdade. Um evento é um fato ocorrido no sistema: "pedido criado", "pagamento aprovado", "estoque baixado". Cada evento é imutável e carrega dados suficientes para descrever o que aconteceu. O estado atual de um agregado é obtido aplicando todos os eventos em sequência. Se você precisa saber o saldo de uma conta, não consulta uma tabela com o saldo; você reproduz todos os eventos de depósito e saque. O saldo é uma projeção derivada.

Como aplicar event sourcing na prática?

A aplicação exige mudar o modelo mental de persistência. Em vez de atualizar uma linha no banco, você anexa um evento a um log. Cada evento tem um tipo, um identificador de agregado, um timestamp e um payload. Para reconstruir o estado, você lê todos os eventos daquele agregado e aplica as regras de negócio em ordem. Isso é chamado de replay. Em cenários de alto volume, é comum criar snapshots periódicos para evitar reprocessar toda a história.

Um passo prático é definir o modelo de eventos antes de implementar qualquer comando. Pergunte quais mudanças de estado são relevantes para o negócio. Nem toda alteração precisa virar evento. Eventos devem representar fatos, não intenções. Por exemplo, "tentativa de pagamento" pode ser um comando, mas "pagamento processado" é um evento.

Outra decisão importante é onde armazenar os eventos. Bancos relacionais podem ser usados com uma tabela de eventos, mas existem soluções específicas, como event stores, que oferecem suporte a append-only e leitura sequencial. A escolha depende do volume e da necessidade de consistência.

Quando usar event sourcing de verdade?

Event sourcing se justifica em domínios onde o histórico é um requisito de negócio. Auditoria, conformidade regulatória, análise de comportamento e sistemas financeiros são exemplos típicos. Se você precisa responder "como chegamos a este estado?", o padrão entrega isso de forma natural.

Um caso comum é em microsserviços, onde cada serviço mantém seu próprio banco. Event sourcing permite que serviços compartilhem fatos sem acoplar seus esquemas. O Azure Architecture Center, em seu padrão de origem de eventos, alerta que o fornecimento de eventos é um padrão complexo que introduz compensações significativas. Ou seja, não é uma solução para todo projeto.

Quais os riscos e desvantagens?

A principal desvantagem é a curva de aprendizado. A equipe precisa dominar o modelo de eventos, lidar com versionamento de esquemas e garantir consistência eventual. Mudanças na estrutura de um evento exigem migração ou suporte a múltiplas versões. Isso adiciona complexidade operacional.

Outro ponto é a leitura dos dados. Consultas convencionais, como relatórios com filtros e agregações, não são triviais com event sourcing. É comum combinar event sourcing com CQRS, separando o modelo de escrita do modelo de leitura. Sem essa separação, você pode acabar com consultas lentas e código confuso.

A consistência eventual também pode ser um problema. Em sistemas distribuídos, o estado atual pode não refletir imediatamente o último evento. Para aplicações que exigem leitura imediata do dado recém-escrito, o padrão exige cuidado extra.

Como evitar erros comuns na implementação?

Um erro frequente é tentar aplicar event sourcing em todo o sistema. O padrão funciona bem em contextos delimitados, mas não em todos os subsistemas. Comece por um domínio onde o histórico realmente importa. Outro erro é não definir um identificador estável para cada agregado. Sem isso, o replay fica impossível.

Também é essencial tratar eventos como contratos públicos. Uma vez publicado, um evento não pode ser alterado. Se precisar corrigir um fato, crie um novo evento de compensação. Versionar eventos é prática obrigatória. O uso de um barramento de eventos ou message broker pode ajudar no desacoplamento, mas adiciona infraestrutura.

Event sourcing é igual a CQRS?

Não. CQRS é um padrão que separa operações de leitura e escrita em modelos distintos. Event sourcing é uma forma de persistência baseada em eventos. Eles se complementam, mas podem ser usados de forma independente. Você pode ter CQRS sem event sourcing, e event sourcing sem CQRS, embora a combinação seja comum em arquiteturas de microsserviços.

Como event sourcing se relaciona com microsserviços?

Em microsserviços, cada serviço é dono do seu dado. Event sourcing permite que um serviço publique eventos que outros consomem, sem expor tabelas internas. Isso reduz o acoplamento e facilita a evolução independente. O Medium, em artigo sobre event sourcing em microsserviços, descreve o padrão como uma forma de computar o estado atual de um agregado pela sequência de eventos armazenados. Na prática, cada serviço mantém seu próprio log de eventos e pode reconstruir seu estado quando necessário.

Resumo

Event sourcing é um padrão poderoso para domínios que exigem rastreabilidade total e reconstrução de estado. Ele não é simples e introduz compensações em armazenamento, leitura e consistência. Aplique com cautela, comece por um contexto específico e combine com CQRS quando precisar de consultas eficientes. Avalie o custo operacional antes de adotar em toda a arquitetura.

Perguntas frequentes

Event sourcing substitui o banco de dados tradicional?

Não substitui por completo. O log de eventos é a fonte primária, mas você ainda precisa de projeções para leitura e consultas. Muitas implementações usam um banco relacional ou NoSQL para armazenar as projeções, enquanto o event store guarda os eventos.

Quais linguagens suportam event sourcing?

Todas as linguagens de programação podem implementar o padrão. A escolha de bibliotecas e frameworks varia. Em Java, por exemplo, Axon Framework é comum. Em Node.js, há opções como o EventStore. O padrão independe da linguagem.

Event sourcing é adequado para projetos pequenos?

Em projetos pequenos, o custo de implementação pode superar o benefício. A menos que haja requisito de auditoria ou histórico, um CRUD tradicional resolve. Avalie a complexidade do domínio antes de decidir.

Como lidar com a evolução do modelo de eventos?

Use versionamento de eventos. Cada evento carrega um version, e o código deve ser capaz de lidar com múltiplas versões. Novos campos podem ser adicionados com valores padrão. Eventos antigos nunca são alterados.

O que é replay de eventos?

Replay é o processo de reprocessar todos os eventos de um agregado para reconstruir o estado atual. É usado em recuperação de falhas, debug e para gerar novas projeções. Em sistemas de longa duração, snapshots reduzem o custo do replay.