Consistência eventual (BD)
A garantia de consistência mais fraca em uso comum: se não houver novas escritas, todas as réplicas acabarão convergindo para o mesmo valor. Nada se diz sobre quanto tempo isso leva nem sobre o que você vê enquanto isso — só que, no fim, ficam iguais.
A ideia é priorizar disponibilidade e baixa latência em vez de consistência imediata. As réplicas podem divergir temporariamente (uma leitura logo após a escrita pode devolver dado "velho"), mas mecanismos de reparo (read repair, anti-entropia) garantem a convergência. Exemplos clássicos: DNS (uma mudança leva minutos ou horas para se espalhar), Cassandra/Dynamo nos modos mais fracos e o S3 (historicamente). Ganho: alta disponibilidade, tolerância a partições e escalabilidade (AP no CAP). Preço: a aplicação precisa tolerar valores desatualizados e, eventualmente, conflitos. "Eventual" é notoriamente vago → variantes mais fortes, como read-your-writes e consistência causal, acrescentam garantias práticas por cima. O oposto da consistência forte/linearizável. Relacionada à consistência causal e à replicação sem líder.