System Design/01 - Fundamentos1 minindice
Consistency Patterns
Tópicos
Perguntas-guia
- Como esses tópicos se encaixam entre si?
- Qual escolher em qual cenário?
Visão geral
Os três modelos formam uma escala, do mais caro e mais garantido ao mais barato e mais frouxo:
| Modelo | Garantia | Custo | Use para |
|---|---|---|---|
| Strong Consistency | Toda leitura vê a última escrita | Latência + disponibilidade | Saldo, estoque, reserva de assento |
| Eventual Consistency | Converge em algum momento | Complexidade na aplicação | Feed, contador, perfil, catálogo |
| Weak Consistency | Nenhuma garantia de convergência | Dado perdido é perdido | VoIP, streaming, jogo em tempo real |
A pergunta que escolhe entre eles: qual o custo de ler um valor obsoleto?
- Custo irreversível (assento vendido duas vezes, saldo negativo) → forte
- Custo cosmético (contador desatualizado por 2 s) → eventual
- A informação envelhece mais rápido que o custo de recuperá-la → fraca
O erro mais frequente é aplicar consistência forte a tudo "por segurança". A maior parte dos dados de um sistema real tolera atraso, e pagar coordenação por eles gasta latência sem ganho nenhum.
Entre forte e eventual existem garantias intermediárias que resolvem os sintomas mais irritantes sem pagar o preço cheio: read-your-own-writes, monotonic reads e consistent prefix.
Parte de 01 - MOC Fundamentos · roadmap.sh/system-design