System Design/01 - Fundamentos2 min
Strong Consistency
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Depois que uma escrita é confirmada, toda leitura subsequente — de qualquer nó — retorna aquele valor. O sistema se comporta como se houvesse uma única cópia do dado.
O nome formal mais preciso é linearizabilidade: existe uma ordem total das operações, e essa ordem respeita o tempo real. Se a escrita A terminou antes da leitura B começar, B tem que ver A.
Como se consegue
| Mecanismo | Como funciona |
|---|---|
| Escrita síncrona em quórum | Confirma só depois que a maioria dos nós gravou |
| Consenso (Raft, Paxos) | Um líder eleito ordena todas as escritas |
| Two-phase commit | Coordenador garante que todos commitam ou nenhum |
| Leitura no líder | Só o nó primário responde leituras |
A regra de quórum: com N réplicas, escrever em W e ler de R, garante consistência se W + R > N. Com N=3, W=2, R=2 funciona.
Trade-offs
Consistência forte custa em latência e disponibilidade, sempre:
- Latência: cada escrita espera confirmação da maioria. Entre regiões, isso significa dezenas ou centenas de milissegundos por operação.
- Disponibilidade: se a maioria não está alcançável, o sistema recusa a operação — é o lado CP do CAP Theorem.
- Throughput: coordenação serializa; o líder vira gargalo de escrita.
Pelo PACELC, mesmo sem partição você paga: consistência forte e latência baixa são inimigas naturais.
O erro comum é aplicar consistência forte a tudo "por segurança". A maior parte dos dados de um sistema real (contador de visualizações, feed, cache de perfil) tolera atraso — e pagar coordenação por eles é desperdiçar latência sem ganho.
Exemplo prático
Onde é obrigatória: saldo bancário, reserva de assento, estoque de item único, alocação de nome de usuário. Em todos, ler um valor obsoleto produz um erro que não dá para desfazer barato — assento vendido duas vezes, saldo negativo.
Como aparece na prática: um SELECT ... FOR UPDATE numa transação, ou uma escrita condicional (compare-and-swap) que falha se o valor mudou.
Onde é desperdício: número de curtidas de um post. Se dois usuários veem 1.204 e 1.205 no mesmo instante, ninguém se importa — e forçar consenso nisso a cada clique derrubaria o sistema.
Relacionado
Parte de Consistency Patterns · roadmap.sh/system-design