Eventual consistency: o que é em sistemas distribuídos

Eventual consistency, ou consistência eventual, é um modelo de consistência em sistemas distribuídos que garante que, se nenhuma nova atualização for feita em um dado, todas as réplicas convergem para o mesmo valor ao longo do tempo. Ou seja, o sistema não exige que todas as cópias estejam idênticas a cada instante, mas promete que, em algum momento futuro, elas ficarão sincronizadas. Esse modelo é usado para alcançar alta disponibilidade em ambientes distribuídos, conforme define a Wikidata (2026).

Como funciona a eventual consistency?

Em um sistema distribuído, os dados são replicados em vários nós para garantir disponibilidade e tolerância a falhas. Na eventual consistency, quando um nó recebe uma escrita, ele propaga a atualização para os demais de forma assíncrona. Durante esse intervalo, um nó pode responder a uma leitura com um valor antigo. O sistema aceita essa inconsistência temporária porque a propagação é feita em segundo plano, sem bloquear a operação.

O ponto central é o termo "eventual": não há prazo definido para a convergência. O sistema apenas garante que, cessadas as escritas, todas as réplicas chegarão ao mesmo estado. Na prática, o tempo de convergência depende da infraestrutura e da carga, mas a garantia lógica se mantém.

Eventual consistency vs strong consistency: qual a diferença?

A strong consistency (consistência forte) exige que toda leitura retorne o valor da escrita mais recente, mesmo que isso custe latência e disponibilidade. Em contraste, a eventual consistency permite que leituras retornem dados desatualizados por um período, mas garante convergência futura. Essa diferença fica clara em um exemplo simples: em um sistema de carrinho de compras, a strong consistency garantiria que todos os nós veem o item adicionado imediatamente; a eventual consistency pode exibir o carrinho sem o item por alguns instantes até a réplica ser atualizada.

A escolha entre os dois modelos envolve um trade-off. A strong consistency é adequada para sistemas financeiros ou de reservas, onde dados desatualizados causam prejuízo. A eventual consistency é mais comum em redes sociais, sistemas de recomendação e cache distribuído, onde a disponibilidade importa mais que a leitura instantânea.

Quando usar eventual consistency?

A eventual consistency é indicada quando a aplicação tolera leituras eventualmente desatualizadas e prioriza disponibilidade contínua, mesmo em cenários de partição de rede. Casos típicos: feeds de notícias, contadores de visualizações, sistemas de comentários e DNS. Nesses contextos, uma resposta rápida com dado antigo é melhor que uma falha de serviço.

Um contraexemplo claro: um sistema de transferência bancária não deve usar eventual consistency, pois o saldo precisa ser preciso no momento da transação. A ressalva prática é que, em sistemas com escrita concorrente no mesmo dado, a eventual consistency exige estratégias extras, como versionamento ou resolução de conflitos, para evitar perda de atualizações.

Quais as vantagens e limitações?

A principal vantagem é a alta disponibilidade: o sistema continua respondendo mesmo que alguns nós estejam fora do ar. Também reduz a latência, pois escritas não precisam aguardar confirmação de todos os nós. Em contrapartida, a limitação é a janela de inconsistência, que pode ser problemática em domínios que exigem leitura imediata do valor mais recente.

Outra limitação é a complexidade de resolução de conflitos. Se dois nós recebem escritas concorrentes para o mesmo dado, o sistema precisa de uma política para decidir qual valor prevalece, como last-write-wins ou merge de versões. Isso adiciona lógica à aplicação, o que nem sempre é trivial.

Como a eventual consistency é implementada na prática?

A implementação típica envolve replicação assíncrona entre nós, com mecanismos de propagação como gossip protocol ou filas de mensagens. Cada nó mantém uma versão local do dado e aplica as atualizações recebidas em segundo plano. Sistemas como DynamoDB e Cassandra usam esse modelo, mas a implementação específica varia conforme o produto.

O artigo científico "Eventual Consistency: Origin and Support" (Wikidata, 2026) e a patente "Eventual consistency in a deduplicated cloud storage system" (US patent 11507550, Wikidata, 2026) mostram que o conceito é objeto de estudo e aplicação em diferentes cenários. Na prática, a configuração exige definir parâmetros como número de réplicas e política de conflito, sempre com base no requisito de negócio.

Resumo

Eventual consistency é um modelo que equilibra disponibilidade e atualidade dos dados. Ele não serve para todo sistema, mas é a escolha certa quando a tolerância a leituras antigas é aceitável. Antes de adotá-lo, avalie o custo de uma resposta desatualizada no seu domínio.

Perguntas frequentes

Eventual consistency pode perder dados?

Não necessariamente. A eventual consistency garante que as escritas serão propagadas, mas se dois nós recebem escritas concorrentes sem uma política de resolução, uma atualização pode ser sobrescrita. Por isso, é essencial definir regras de conflito, como timestamp ou versão, para evitar perda de dados.

Qual a diferença entre eventual consistency e consistência forte?

A consistência forte exige que toda leitura reflita a última escrita, bloqueando o acesso até a sincronização. A eventual consistency permite leituras desatualizadas temporariamente, mas promete convergência futura. A escolha depende do trade-off entre disponibilidade e precisão.

Eventual consistency é usada em bancos relacionais?

Bancos relacionais tradicionais priorizam consistência forte, mas alguns bancos NoSQL, como Cassandra e DynamoDB, usam eventual consistency por padrão. Em bancos relacionais, é possível configurar replicação assíncrona, mas o modelo padrão não é eventual.

Como resolver conflitos na eventual consistency?

A resolução de conflitos pode usar políticas como last-write-wins (baseada em timestamp), merge de versões ou vetores de versão. A escolha depende do tipo de dado e da tolerância a perda de atualização. Em dados contadores, por exemplo, um merge é mais adequado que sobrescrever.

Eventual consistency é adequada para sistemas financeiros?

Em geral, não. Sistemas financeiros exigem consistência forte para evitar saldos incorretos ou transações duplicadas. A eventual consistency é mais adequada para casos onde a leitura antiga é aceitável, como contadores de likes ou cache.

Quanto tempo leva para a convergência acontecer?

Não há prazo garantido. A convergência depende da propagação assíncrona, da carga do sistema e da infraestrutura. Em redes saudáveis, ocorre em milissegundos, mas em partições de rede pode levar mais tempo. O modelo apenas garante que, sem novas escritas, a convergência ocorre.