Pular para o conteúdo

apps/data-patterns/event-sourcing

079 · Dados & Persistência · ≈ 6 min de estudo

Event Sourcing

Em vez de gravar o estado atual, cada mudança da conta é gravada como um evento imutável, em ordem, num log append-only. O saldo é sempre derivado, dobrando os eventos com uma função pura. Use quando o histórico tem valor de negócio: auditoria regulatória, “como chegamos neste saldo”, saldo em qualquer data passada.

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

Cenário

Conta corrente de banco digital: abertura, depósitos e saques por PIX, TED e boleto viram eventos EventAccountOpened, EventAccountMoneyDeposited e EventAccountMoneyWithdrawn. O saldo não existe em coluna nenhuma — sai do replay. Dois saques simultâneos que juntos passam do saldo não podem passar os dois.

Planta

Sequência
8/8
alt[outro comando gravou a version 5 antes]saque de R$ 1.500,001snapshot mais recente2eventos com version maior que o snapshot3fold puro, saldo na versão 44decide: saldo cobre o saque, gera EventAccountMoneyWithdrawn5INSERT version 5623505 em uq_event_store_aggregate_version7recarrega, decide de novo sobre o saldo novo8a cada 50 eventos o estado vira snapshotUPDATE, DELETE e TRUNCATE barrados por triggerComandostore_accountevent_storeevent_snapshot
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Log de eventos é a fonte da verdade.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    decide valida a regra sobre o estado atual e devolve eventos; accountEventApply só dobra eventos, sem I/O e sem rejeitar fato passado

  2. 02

    O append grava na versão esperada + 1; a chave única (aggregate_id, version) faz o segundo escritor falhar com 23505

  3. 03

    No conflito o comando recarrega o estado e decide de novo — nunca repete o mesmo INSERT

  4. 04

    A cada 50 eventos o estado vira snapshot; a carga parte dele e aplica só a cauda

  5. 05

    Payload antigo nunca é reescritoO upcaster converte a versão 1 (reais em texto) para centavos na leitura

  6. 06

    Time travelReplay só dos eventos com created_at até o instante pedido; todo evento leva correlationId, causationId, userId e channel

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • Auditoria completa e imutável por construção

  • Saldo em qualquer data passada

  • Concorrência otimista sem lock explícito

Custos

  • Leitura exige replay ou projeção

  • Log cresce sem fim: retenção e arquivamento a definir

  • Mudança de schema pede upcaster permanente

apps/data-patterns/event-sourcing

7 arquivos

sql/

  • 01_schema.sqlschemaevent_store append-only com trigger, event_snapshot

src/

  • event_account.tsEventos, fold puro, decisões e upcaster
  • store_account.tsAppend com concorrência otimista, carga com snapshot, time travel
  • demo.tsdemoStream, recusa, time travel, corrida, snapshot e log imutável
  • event_account.test.tstesteFold, snapshot, limite do saque e upcaster sem banco
  • store_account.test.tstesteImutabilidade, conflito de versão, snapshot e time travel contra PostgreSQL real

src/config_account.ts / src/

  • pool_account.tsAmbiente validado, pool e transactionExecute

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Por que se relacionam

Teste rápido

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

Próximo projeto · Dados & PersistênciaOutbox Pattern
Esc

↑ ↓ navegarEnter abrir191 resultados