System Design/04 - Cloud Design Patterns/Data Management2 min
Event Sourcing
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Em vez de guardar o estado atual, guarda-se a sequência imutável de eventos que produziu esse estado. O estado é derivado reproduzindo os eventos.
tradicional: conta { saldo: 150 }
event sourcing:
ContaAberta { saldo: 0 }
Depositado { valor: 200 }
Sacado { valor: 50 }
→ saldo atual = 150 (calculado)
O log de eventos é append-only: nunca se altera nem se apaga. Corrigir significa adicionar um evento compensatório.
Conceitos que acompanham
| Conceito | Papel |
|---|---|
| Snapshot | Estado materializado a cada N eventos, para não reproduzir tudo |
| Projeção | Visão de leitura construída dos eventos (Materialized View) |
| Replay | Reconstruir o estado, ou construir uma projeção nova do histórico |
Trade-offs
O que se ganha é raro e valioso: auditoria completa e gratuita, capacidade de responder "como estava em qualquer instante do passado", depuração por reprodução, e a possibilidade de criar projeções novas a partir do histórico — inclusive para responder perguntas que ninguém tinha feito quando o dado foi gravado.
O que se paga é substancial:
| Custo | Detalhe |
|---|---|
| Complexidade | Modelo mental muito diferente; time precisa aprender |
| Consulta | "Qual o saldo?" não é um SELECT — exige projeção |
| Versionamento de evento | Eventos são eternos; mudar o schema exige upcasting |
| Volume | O log só cresce |
| Exclusão de dados | Log imutável conflita com direito ao esquecimento |
O último merece atenção: legislações de privacidade exigem apagar dados pessoais, e o padrão foi desenhado para nunca apagar nada. As saídas (criptografia por titular com descarte da chave) funcionam e adicionam mais complexidade.
Por isso event sourcing raramente deve ser aplicado ao sistema inteiro. Ele compensa nos domínios em que o histórico é o valor — financeiro, auditoria, controle de estoque — e é peso morto no resto.
Exemplo prático
Um sistema bancário. O saldo não é um campo; é o resultado de somar os lançamentos.
Isso resolve de graça três requisitos que, no modelo tradicional, seriam trabalho: o extrato completo já existe; "qual era o saldo no dia 3?" é reproduzir até aquela data; e um erro operacional é corrigido por um lançamento de estorno, preservando o registro do que aconteceu.
Compare com um UPDATE saldo = 150: a informação de como se chegou a 150 simplesmente não existe. Recuperá-la depois exigiria uma tabela de auditoria — que é event sourcing feito pela metade e sem garantias.
Relacionado
Parte de Data Management · roadmap.sh/system-design