Eventually consistent: o que é e quando usar
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 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.
