System Design/01 - Fundamentos2 min
Eventual Consistency
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Depois de uma escrita, as réplicas divergem por um período — mas, cessadas as escritas, todas convergem para o mesmo valor. A garantia é sobre o destino, não sobre o prazo.
É o modelo padrão de sistemas AP: aceita-se a escrita localmente e propaga-se em background.
t0 escrita em A A=novo B=antigo C=antigo
t1 propagação A=novo B=novo C=antigo
t2 convergência A=novo B=novo C=novo
A janela entre t0 e t2 é a janela de inconsistência. Ela é tipicamente de milissegundos, mas não há garantia formal — sob partição, pode durar o tempo da partição.
Como as réplicas resolvem divergência
| Mecanismo | Como decide |
|---|---|
| Last Write Wins (LWW) | Timestamp mais recente vence — simples e perde escritas |
| Vector clocks | Detecta conflito real vs. ordem causal; devolve os dois para a aplicação decidir |
| CRDTs | Estruturas que convergem matematicamente, sem conflito possível |
| Read repair | A leitura detecta réplica atrasada e a corrige |
| Anti-entropy / Merkle trees | Comparação periódica em background |
Garantias intermediárias úteis
Entre forte e eventual existem modelos que resolvem os sintomas mais irritantes:
- Read-your-own-writes: você sempre vê suas próprias escritas (mesmo que outros ainda não)
- Monotonic reads: você nunca vê o tempo "andar para trás"
- Consistent prefix: você vê as escritas na ordem em que aconteceram
Trade-offs
Ganha-se disponibilidade, latência baixa e escala horizontal — escrever em qualquer réplica, sem coordenação. Perde-se a simplicidade de raciocínio: a aplicação precisa lidar com dado obsoleto e, às vezes, com conflitos.
O custo escondido está na lógica de negócio. "Últimas 24h de vendas" pode divergir entre duas telas. Uma decisão tomada sobre dado obsoleto pode ser errada. Isso empurra complexidade da infraestrutura para o código de domínio.
LWW merece atenção especial: é o mecanismo mais usado e silenciosamente descarta escritas concorrentes. Com relógios dessincronizados entre máquinas, pode descartar a escrita mais recente.
Exemplo prático
Você publica um comentário e recarrega a página — o comentário sumiu. A escrita foi para a réplica A, a leitura veio da réplica B, que ainda não replicou.
A correção não é abandonar consistência eventual; é adicionar read-your-own-writes: por alguns segundos após uma escrita, direcione as leituras daquele usuário para a réplica que recebeu a escrita (ou para o primário). O resto do mundo continua eventualmente consistente, e o autor nunca vê o próprio comentário desaparecer.
Relacionado
Parte de Consistency Patterns · roadmap.sh/system-design