Pular para o conteúdo

apps/patterns/event-sourcing

013 · Padrões Fundamentais · ≈ 6 min de estudo

Event Sourcing

Em vez de guardar o estado atual, guarda cada fato que mudou o estado num log append-only e imutável; o estado é sempre derivado pelo replay dos eventos. Dá auditoria completa de cada centavo, reconstrução de qualquer momento passado e várias projeções sobre os mesmos fatos. Use quando o histórico tem valor regulatório ou de negócio.

passos
6
arquivos
8
testes
2
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
Baixar cartão

Cenário

A conta de Alice nasce, recebe um depósito, faz um saque e tem um saque acima do saldo recusado — nada é gravado. Um depósito antigo, gravado no schema v1 (reais em texto), é lido pelo upcaster. O saldo vem do snapshot mais o resto do log; o time travel mostra o saldo na versão 2 e logo depois do depósito. Por fim, dois saques concorrentes disputam a versão 5 e o perdedor recarrega e grava na 6.

Planta

Sequência
11/11
alt[versão já escrita por outro][gravado]carrega snapshot (versão 3)1eventos com versão maior que 32fold do snapshot com os eventos posteriores3estado atual (versão v)4comando sobre o estado5evento no passado (ou recusa)6INSERT versão v + 17235058recarrega e decide de novo9ok10a cada 3 versões, novo snapshot11Serviço de contaaccountCommandDecidePostgreSQL eventsPostgreSQL snapshotsaccountEventApply (fold)
11

11 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Estado reconstruído a partir de eventos.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    Eventos no passadoAccountOpened, MoneyDeposited, MoneyWithdrawn, AccountFrozen — com payload em centavos e metadata (correlationId, channel)

  2. 02

    Fold puroaccountEventApply reconstrói o estado sem I/O e nunca recusa um fato já gravado

  3. 03

    Regras no comandoaccountCommandDecide recusa conta inexistente, congelada, valor inválido ou saldo insuficiente — antes de gravar

  4. 04

    Concorrência otimistaUNIQUE (aggregate_id, version) rejeita a segunda escrita com 23505; o comando recarrega e decide de novo, nunca repete às cegas

  5. 05

    SnapshotA cada N versões o estado é salvo; a leitura aplica só os eventos posteriores

  6. 06

    Evolução e time travelO upcaster converte o payload antigo na leitura, sem reescrever o log; o replay para numa versão ou num instante

apps/patterns/event-sourcing

8 arquivos

sql/

  • 01_schema.sqlschemaTabelas events (append-only, versão única) e snapshots

src/

  • event_account.tsEventos, fold, decisão do comando e upcaster
  • store_event.tsAppend com concorrência otimista, carga com snapshot, time travel e execução do comando
  • config_account.tsLê e valida o ambiente no boot
  • event_account.test.tstesteFold, fronteira do saldo, recusas e upcaster
  • store_event.test.tstesteIntegração contra PostgreSQL: conflito, corrida, snapshot, time travel, metadata
  • demo.tsdemoHistórico, upcast, snapshot, time travel e corrida

./

  • docker.shinfraSobe o PostgreSQL com o schema

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário

Testes: bun run test.

Requisitos
BunDocker
Sobe junto
PostgreSQL

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Event Sourcing?

Próximo projeto · Padrões FundamentaisEventual Consistency
Esc

↑ ↓ navegarEnter abrir191 resultados