Pular para o conteúdo

apps/data-patterns/eventual-consistency

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

Eventual Consistency

Réplicas regionais aceitam escrita sozinhas — escolha AP do teorema CAP — e divergem durante uma partição. Quando a rede volta, um processo de anti-entropy leva as mudanças de uma réplica à outra e as duas convergem sem coordenação síncrona. Use quando disponibilidade e latência local valem mais que leitura sempre atual.

passos
6
arquivos
7
teste
1
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
Baixar cartão

Cenário

Banco digital com réplicas em São Paulo e no Rio. O backoffice ajusta o limite de crédito em qualquer região; compras geram cashback e o cliente resgata em qualquer região. Durante uma partição as duas regiões seguem atendendo. Quando a rede volta, as duas precisam mostrar o mesmo limite e o mesmo cashback, sem perder crédito nenhum.

Planta

Sequência
6/6
partição - cada região escreve sozinhalimite R$ 8.000 (versão 2, origem sp)1limite R$ 6.000 (versão 2, origem rj)2cashback +R$ 15 no contador de sp3cashback +R$ 7 e resgate R$ 10 no contador de rj4rede volta - anti-entropy nos dois sentidoslinhas de SP5linhas de RJ6limite: vence (versão, origem) maior, igual nas duascashback: max por nó, soma de créditos menos débitosRéplica SPRéplica RJ
6

6 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Consistência alcançada com o tempo.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

  1. 01

    Limite de crédito é valor substituívelRegistro LWW com version monotônica e origin_node como desempate — a mesma ordem total em todo nó, então empate converge

  2. 02

    Cashback é PN-Counter (CRDT)Cada nó só incrementa os próprios totais de crédito e débito; nenhuma escrita regional se perde

  3. 03

    Anti-entropy exporta as linhas de uma réplica e faz upsert na outra só quando a linha recebida é mais nova — idempotente, pode rodar de novo ou nos dois sentidos

  4. 04

    Conta encerrada vira tombstone (closed = true numa versão nova): réplica atrasada não a ressuscita

  5. 05

    A leitura devolve updatedAt, para o app mostrar a idade do dado; cada passada mede o lag e alerta acima de REPLICA_LAG_SLO_MS

  6. 06

    Resgate valida só a visão localDuas regiões podem resgatar o mesmo cashback — por isso débito de dinheiro real vai para o primário com consistência forte

Trade-offs

O que se ganha, o que se paga

Aspecto Consistência eventual Consistência forte
Escrita Local, baixa latência Espera quórum ou primário
Partição Segue atendendo Recusa ou bloqueia
Leitura Pode ser stale Sempre atual
Conflito LWW descarta um lado; CRDT preserva ambos Não existe
Uso Limite configurável, cashback, cache regional Débito de saldo, estoque crítico

apps/data-patterns/eventual-consistency

7 arquivos

./

  • docker-compose.ymlinfraDuas réplicas PostgreSQL, SP em 5432 e RJ em 5433

sql/

  • 01_schema.sqlschemaaccount_limits (LWW com tombstone) e cashback_counters (PN-Counter)

src/

  • replica_bank.tsEscritas locais e leitura com updatedAt
  • reconcile_replica.tsAnti-entropy idempotente com medida de lag
  • config_replica.tsVariáveis de ambiente validadas no boot
  • demo.tsdemoPartição, divergência e convergência
  • reconcile_replica.test.tstesteLeitura stale, empate LWW, CRDT, idempotência, tombstone e o custo AP contra duas réplicas reais

Executar · com Docker

  1. docker compose up -d --wait# 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 padrão vem antes de Eventual Consistency?

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

↑ ↓ navegarEnter abrir191 resultados