Escolher como persistir os dados de uma aplicação não é apenas uma decisão de armazenamento. Isso define o que pode ser reconstruído, como as alterações podem ser explicadas e quanto trabalho será necessário para manter o sistema. O event sourcing guarda uma sequência de eventos como fonte da verdade; um modelo tradicional costuma guardar o estado atual e, se necessário, um histórico complementar.
Nenhuma opção é superior em todos os casos. A pergunta útil é quando o histórico completo e a possibilidade de reconstrução oferecem valor suficiente para justificar uma arquitetura mais exigente. Este guia propõe critérios práticos para decidir, identificar alternativas mais simples e começar com um escopo controlado.
O que significa event sourcing e o que muda em relação ao modelo tradicional
No event sourcing, a aplicação registra fatos de negócio que já aconteceram, como PedidoCriado, PagamentoConfirmado ou EndereçoAtualizado. O estado atual é obtido pela aplicação desses eventos em ordem. Em vez de sobrescrever uma linha com o último valor, conserva-se uma sequência que descreve como a entidade evoluiu.
Em um modelo tradicional, o banco de dados normalmente contém a versão atual: por exemplo, o estado atual de um pedido e o seu valor. Uma atualização substitui os valores anteriores. Se for necessário saber quem alterou um dado, quando isso aconteceu ou qual era o valor anterior, pode-se acrescentar um registro de auditoria ou um histórico específico.
A diferença decisiva não é que uma abordagem tenha histórico e a outra não. É qual registro é a autoridade. No event sourcing, os eventos são a fonte da verdade e as visualizações atuais são derivadas deles. Em um modelo tradicional, o estado persistido costuma ser a autoridade; quando existe, o histórico cumpre uma função adicional.
Comece pelo problema, não pela arquitetura
Antes de escolher, defina que pergunta de negócio você não consegue responder hoje. “Queremos mais rastreabilidade” é demasiado genérico; “precisamos reconstruir quais decisões produziram o saldo de uma conta em determinada data” descreve uma necessidade verificável. Essa precisão permite comparar soluções sem adotar uma arquitetura apenas por seu apelo técnico.
- Histórico: é necessário consultar alterações anteriores, mas não necessariamente reconstruir todo o estado. Um registro de auditoria pode ser suficiente.
- Reconstrução: é preciso recalcular o estado a partir de fatos conservados, por exemplo, para corrigir uma regra de negócio ou analisar uma situação histórica.
- Rastreabilidade: é importante explicar o que aconteceu e em que ordem. Isso pode ser resolvido com eventos de negócio ou com um histórico concebido para esse fim.
- Consultas atuais: a maioria das telas só precisa ler o estado atual. Um modelo tradicional pode oferecer um caminho mais direto.
Também convém verificar se o requisito é permanente e central para o produto ou se aparece em apenas um processo. O event sourcing faz mais sentido quando a sequência de alterações é parte essencial do domínio, e não apenas quando alguém quer “guardar tudo”.
Critérios práticos para decidir
Avalie cada critério com exemplos reais do domínio. Não é necessário que todos apontem para o event sourcing, mas é importante compreender qual requisito está orientando a escolha.
- As alterações têm significado próprio: “reserva confirmada” ou “reembolso aprovado” são fatos relevantes, não simples mudanças de campos. Isso favorece a modelagem de eventos explícitos.
- A reconstrução é necessária: o negócio precisa voltar a obter estados anteriores ou recalculá-los com novas regras. Se a necessidade for apenas mostrar as alterações mais recentes, um histórico pode ser suficiente.
- A ordem importa: a sequência de ações determina o resultado, e a equipe precisa conservá-la de forma confiável.
- Há várias visualizações do mesmo processo: diferentes equipes ou funções precisam consultar os mesmos fatos de maneiras distintas. As projeções podem atender a essas leituras, embora acrescentem trabalho.
- O domínio tem correções e exceções: elas devem ser representadas como novos fatos — por exemplo, uma correção ou reversão — sem apagar silenciosamente o que aconteceu. É necessário definir com cuidado o significado de cada evento.
Se a necessidade se limitar a atualizar registros e consultar a versão atual, o modelo tradicional provavelmente será mais simples. Se o histórico precisar ser completo, compreensível e utilizável para derivar estados, o event sourcing merece uma avaliação mais aprofundada.
Custos, riscos e sinais para descartá-lo
Guardar eventos não elimina a complexidade: apenas a desloca. As leituras costumam depender de projeções, isto é, visualizações derivadas que são atualizadas a partir dos eventos. Se elas forem processadas de forma assíncrona, pode haver consistência eventual: durante um intervalo, uma leitura refletirá um estado anterior. O produto precisa tolerar isso ou definir como apresentar e administrar esse atraso.
Além disso, os eventos persistidos não são editados como linhas comuns. Quando o domínio muda, é preciso decidir como interpretar eventos antigos, como os formatos vão evoluir e como as projeções serão reconstruídas. Também são necessários procedimentos para detectar falhas de processamento, repetir eventos com segurança e manter as operações e o suporte. Uma sequência incompleta ou mal definida pode prejudicar justamente a reconstrução que se pretendia viabilizar.
Convém descartar ou adiar o event sourcing se a equipe não consegue explicar quais eventos representam fatos de negócio, se as consultas necessárias são simples ou se o sistema não precisa de reconstrução. Também é um sinal de alerta quando o principal argumento é “ter auditoria”, sem requisitos relativos a consultas históricas, retenção ou uso desse registro. Nesses casos, uma tabela de histórico bem concebida pode cumprir o objetivo com menos componentes.
Exemplo hipotético: pedidos com alterações e correções
Imaginemos uma aplicação que gerencia pedidos. A equipe precisa mostrar o estado, o valor e o endereço atuais. Um modelo tradicional com os dados do pedido e um histórico de alterações pode ser suficiente se o objetivo for consultar a versão atual e explicar modificações recentes.
A decisão muda se o negócio precisar reconstruir como se chegou ao valor, distinguir confirmações de correções e recalcular situações históricas segundo novas regras. O event sourcing poderia registrar fatos como pedido criado, pagamento confirmado e valor corrigido. A visualização do pedido seria derivada dessa sequência. Mas seria necessário decidir como representar uma correção, como lidar com eventos antigos e quais leituras poderiam exibir dados temporariamente desatualizados.
O exemplo não significa que todo processo de pedidos precise de event sourcing. A escolha depende de requisitos verificáveis: que reconstrução é exigida, quem consulta o histórico e que nível de complexidade a equipe consegue operar.
Perguntas de verificação antes de adotar event sourcing
- Que pergunta concreta não pode ser respondida com o estado atual e um histórico simples?
- Que entidades ou processos precisam de reconstrução e com qual objetivo de negócio?
- Os eventos descrevem fatos com significado estável ou apenas copiam alterações técnicas de campos?
- Que visualizações precisam ser mantidas, quem as utiliza e quanto atraso pode tolerar?
- Como serão tratadas correções, eventos duplicados, mudanças de formato e reprocessamentos?
- Quem será responsável por monitorar as projeções e resolver falhas de processamento?
- Existe uma alternativa mais simples que atenda aos requisitos atuais sem limitar opções futuras?
Comece com um escopo limitado e reveja a decisão
Se os requisitos justificarem o event sourcing, limite a adoção a um processo cujo histórico tenha valor claro. Primeiro, defina o vocabulário dos eventos com as pessoas responsáveis pelo domínio e combine o que cada evento garante: o que aconteceu, que dados são necessários para interpretá-lo e o que não deve mudar depois. Planeje também as principais consultas e a recuperação das projeções antes de ampliar o escopo.
Registre as decisões e reveja a arquitetura quando as necessidades mudarem. Se o produto deixar de exigir reconstrução, ou o custo de manter projeções superar sua utilidade, simplificar pode ser razoável. Se surgirem novos requisitos de rastreabilidade e análise, um histórico convencional pode deixar de ser suficiente. A melhor escolha é aquela que responde a necessidades reais e que a equipe consegue operar com confiabilidade, não a que acumula mais mecanismos de forma antecipada.