Pular para o conteúdo

apps/data-patterns/snapshot-pattern

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

Snapshot Pattern

Em event sourcing o estado vem do replay dos eventos, e o replay cresce com a idade do agregado. O snapshot guarda o estado dobrado numa versão; a carga parte dele e aplica só os eventos posteriores. O snapshot é cache: pode ser apagado, recriado ou ignorado a qualquer momento sem perder nada.

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

Cenário

Conta corrente com anos de depósitos, saques e juros. Recalcular o saldo dobrando todos os eventos a cada operação fica mais lento conforme a conta envelhece. Com um snapshot a cada 5 eventos, toda carga dobra no máximo 4 eventos, qualquer que seja a idade da conta.

Planta

Sequência
7/7
saque1snapshot com o schema_version atual2estado na v103eventos com version maior que 104v11, v125dobra 2 eventos sobre o snapshot6INSERT v13 com a versão esperada75 eventos desde o último snapshot: grava um novo, fora do caminho críticoschema_version antigo: snapshot ignorado, replay completoComandostore_accountsnapshotsevent_store
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Foto do estado encurta o replay.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

version+2
(aggregate_id, version)+1
  1. 01

    A carga lê o snapshot da conta com o schema_version atual e dobra só os eventos com version maior

  2. 02

    A dobra é pura e em centavos inteiros, com juros arredondados ao centavo: snapshot mais cauda é idêntico ao replay completo

  3. 03

    Depois do comando, se já há SNAPSHOT_EVERY eventos desde o último snapshot, um novo é gravado

  4. 04

    Falhar ao gravar o snapshot não falha o comando — só a próxima carga dobra mais eventos

  5. 05

    Mudou o formato do estado → sobe SNAPSHOT_SCHEMA_VERSION; snapshots antigos são ignorados e reescritos

  6. 06

    A escrita usa a versão esperada; a chave única (aggregate_id, version) barra o escritor desatualizado

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • Carga limitada a N eventos, qualquer idade

  • Snapshot descartável, sem risco para os eventos

  • Política ajustável por agregado

Custos

  • Escrita extra a cada N eventos

  • Mudança de formato exige versão do snapshot

  • Dobra precisa ser exata, senão o snapshot diverge

apps/data-patterns/snapshot-pattern

7 arquivos

sql/

  • 01_schema.sqlschemaevent_store e snapshots com schema_version

src/

  • event_account.tsEventos, dobra pura e decisão de saque
  • store_account.tsAppend com versão, carga por snapshot e política de snapshot
  • demo.tsdemoEventos replayados por carga e snapshot de formato antigo
  • event_account.test.tstesteEquivalência em todos os pontos de corte e limite do saque
  • store_account.test.tstesteLimiar da política, carga pela cauda, schema antigo e conflito contra PostgreSQL real

src/config_snapshot.ts / src/

  • pool_snapshot.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 Snapshot Pattern?

Próximo projeto · Dados & PersistênciaTemporal Tables
Esc

↑ ↓ navegarEnter abrir191 resultados