O Que É Event Sourcing? Armazenando Mudanças, Não Apenas Estado
Event sourcing armazena cada mudança de estado como um evento imutável, e o estado atual é derivado reproduzindo esses eventos em ordem.
Em vez de salvar apenas o estado mais recente, o event sourcing registra o histórico completo do que aconteceu como uma sequência de eventos. O estado atual é um fold sobre esse histórico. Isso te dá uma trilha de auditoria perfeita e a capacidade de reconstruir qualquer estado passado, ao custo de consultas mais complexas e disciplina cuidadosa de esquema.
Eventos como fonte da verdade
O log de eventos é o sistema de registro. Cada evento captura um fato que aconteceu, uma conta foi creditada, um item foi despachado, e nunca é mutado. O estado é computado reproduzindo eventos, então o histórico é sempre completo e auditável.
O que ele te dá
- Uma trilha de auditoria completa e imutável por construção.
- A capacidade de reconstruir estado ou construir novos read models a partir do histórico.
- Time-travel: reconstruir o estado como estava em qualquer momento passado.
- Encaixe natural com CQRS e designs orientados a eventos.
A evolução de esquema é a parte difícil
Eventos antigos vivem para sempre, então uma mudança no formato de um evento precisa permanecer legível. Você versiona eventos e escreve upcasters que traduzem formatos antigos para novos. Erre nisso e o replay quebra, o que torna os testes de esquema de eventos críticos no CI.
Testando replay e projeções
Sistemas com event sourcing são testados alimentando uma sequência de eventos e afirmando o estado e as projeções resultantes. O pipeline também deve verificar que eventos históricos ainda reproduzem corretamente após uma mudança de esquema, o que é um tipo de teste exclusivo do event sourcing.
Deploys e reconstruções
Fazer deploy de uma nova projeção muitas vezes significa reconstruir um read model reproduzindo todo o log de eventos, o que pode ser lento. Os times projetam deploys de forma que as projeções sejam reconstruídas em segundo plano enquanto o read model antigo ainda serve tráfego.
Um perfil de teste mais pesado
Testes de replay-e-reconstrução sobre longos streams de eventos são intensivos em CPU. Runners aquecidos e bem dimensionados (como o Latchkey oferece) evitam que essas suítes mais longas arrastem o loop de feedback.
Principais conclusões
- Event sourcing armazena eventos imutáveis e deriva o estado reproduzindo-os.
- Ele fornece uma trilha de auditoria completa, mas exige versionamento disciplinado de esquema de eventos.
- Deploys podem reconstruir read models reproduzindo o histórico, então planeje isso nos pipelines.