# Eventually consistent: o que é e quando usar

> Eventually consistent é um modelo de consistência de dados em sistemas distribuídos no qual as réplicas convergem para o mesmo estado após um intervalo, sem garantia de leitura imediata. O modelo prioriza disponibilidade e tolerância a partições, sendo indicado para catálogos, feeds e contadores, mas inadequado para transações financeiras ou estoque crítico.

*Pingobox · Apps e Software · 11 de setembro de 2026 · Gustavo Sequeira*

Eventually consistent é um modelo de consistência para sistemas distribuídos em que as réplicas convergem para o mesmo estado após um intervalo. O dado pode estar desatualizado por instantes, mas o sistema não para. Entenda quando vale a pena.

Eventually consistent é um modelo de consistência usado em sistemas distribuídos em que, após uma escrita, as réplicas podem ficar temporariamente divergentes, mas convergem para o mesmo estado desde que novas atualizações cessem. A promessa é simples: o sistema continua respondendo mesmo sob partição de rede, e a consistência chega depois. O preço é leitura desatualizada por um intervalo imprevisível.

## O que significa 'eventualmente' na prática?

Não há prazo garantido. O termo descreve convergência, não velocidade. Em um banco de dados de série temporal com replicação eventual consistente, patenteado nos EUA sob o número 11250019, a janela de divergência depende do volume de escritas, da topologia de replicação e do atraso entre nós. Na prática, pode ser milissegundos em redes locais ou segundos em links intercontinentais. O sistema não promete quando, apenas que, cessadas as escritas, o estado final será o mesmo em todas as réplicas.

## Quando usar eventual consistency?

Use quando a disponibilidade e a latência importam mais do que a leitura perfeitamente atualizada. Três cenários justificam a escolha:

- Contadores e métricas agregadas: exibir 1.002 ou 1.005 curtidas não muda a decisão do usuário.
- Catálogos e feeds: um produto recém-cadastrado aparecer na busca alguns segundos depois é aceitável.
- Sessões e carrinhos: a última atualização de um carrinho pode chegar depois sem quebrar a compra.

O critério mensurável é o custo do dado obsoleto. Se uma leitura desatualizada gera prejuízo financeiro direto, cobrança duplicada ou decisão médica, o modelo não serve.

## Quando evitar?

Evite em transações financeiras com saldo, reservas de estoque com concorrência real e qualquer fluxo em que duas leituras seguidas do mesmo dado precisem ser idênticas. Nesses casos, modelos mais fortes (linearizável ou serializável) são o caminho, mesmo com latência maior. Um sistema de resolução de entidades eventualmente consistente, também patenteado nos EUA (11429697), ilustra o trade-off: a fusão de registros duplicados converge, mas não instantaneamente.

## Como implementar sem surpresas

Três práticas reduzem o risco:

- Leia a própria escrita: roteie a leitura do autor da escrita para o nó que a recebeu.
- Versione o dado: carimbe cada registro com timestamp ou vetor de versão para detectar conflitos.
- Defina SLA de convergência: monitore o atraso de replicação e alerte quando ultrapassar o limite aceitável para o negócio.

A consistência eventual não é um defeito a ser corrigido. É uma escolha arquitetural com custo e benefício claros. O erro comum é adotá-la por padrão e só descobrir o impacto quando o primeiro cliente reclama de dado desatualizado.

## FAQ

### Eventually consistent garante que os dados chegarão?

Garante convergência, não prazo. Se as escritas cessarem, todas as réplicas chegarão ao mesmo estado. O tempo depende da rede, da carga e da topologia. Não há promessa de quando, apenas de que o estado final será idêntico.

### Qual a diferença entre eventual e strong consistency?

Strong consistency exige que toda leitura veja a última escrita confirmada, mesmo que isso custe latência ou indisponibilidade. Eventual consistency aceita leitura desatualizada por um período para manter o sistema disponível e responsivo.

### Eventual consistency viola o teorema CAP?

Não. O teorema diz que sob partição de rede você escolhe entre consistência e disponibilidade. Eventual consistency é a escolha pela disponibilidade, com convergência posterior como mecanismo de reconciliação.

### Posso usar eventual consistency em banco relacional?

Sim, com replicação assíncrona. O primário aceita escritas e as réplicas secundárias aplicam depois. Leituras nas réplicas podem estar atrasadas. O modelo é o mesmo; muda a implementação.

### Como medir o atraso de replicação?

Compare timestamps de commit entre primário e réplicas. A maioria dos bancos expõe métricas de lag. Defina um limite aceitável e alerte quando ultrapassar. O valor varia por carga e topologia.

### Eventual consistency serve para dados financeiros?

Para saldo e transações, não. Para relatórios analíticos, sim. A regra é o custo do dado obsoleto: se uma leitura atrasada gera prejuízo direto, use consistência forte.

---

Fonte (canonical): https://www.pingobox.com.br/apps-e-software/eventually-consistent-o-que-e-e-quando-usar/