System Design/01 - Fundamentos2 min
Weak 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, leituras podem ou não enxergá-la — e o sistema não oferece nenhuma garantia de quando isso passa a valer. Não há promessa de convergência num prazo definido.
É o modelo mais fraco da escala:
Forte ───────────── Eventual ───────────── Fraca
sempre vê vai ver, pode nunca ver
a última em algum momento
A diferença crucial para Eventual Consistency: consistência eventual garante que, cessadas as escritas, todas as réplicas convergem. Consistência fraca não garante nem isso — dado perdido é simplesmente perdido.
Onde aparece por design
| Sistema | Por que a escolha faz sentido |
|---|---|
| VoIP / videochamada | Pacote perdido é ruído; retransmitir chegaria tarde demais |
| Streaming ao vivo | Melhor pular o frame que travar a transmissão |
| Jogo multiplayer em tempo real | Estado é reconciliado pelo próximo tick, não pela retransmissão |
| Memcached | Cache; o miss vai buscar na fonte |
| UDP em geral | Entrega best-effort é o contrato |
Trade-offs
Ganha-se latência mínima e throughput máximo — não há coordenação, não há espera, não há retransmissão. Perde-se qualquer garantia sobre o dado.
Isso só é aceitável quando a informação envelhece mais rápido do que o custo de recuperá-la. Num áudio, o pacote de 20 ms atrás não interessa mais; retransmiti-lo atrapalharia. Num registro financeiro, a mesma perda é inaceitável.
O risco prático é a escolha implícita: sistemas acabam com consistência fraca sem querer — cache sem invalidação, escrita fire-and-forget numa fila sem confirmação, log com buffer que se perde no crash. Consistência fraca deve ser uma decisão declarada, não um acidente.
Exemplo prático
Uma chamada de vídeo perde 2% dos pacotes. O codec preenche a lacuna e a conversa continua — o usuário talvez perceba um artefato de um quadro. Se o protocolo tentasse garantir a entrega de cada pacote, o resultado seria travamento e latência crescente: pior experiência com mais garantia.
Contraste com o chat da mesma chamada: ali a mensagem precisa chegar, e o protocolo muda para TCP com confirmação. Mesmo produto, dois modelos de consistência, escolhidos pelo custo de perder.
Relacionado
Parte de Consistency Patterns · roadmap.sh/system-design