Quais são os modelos de consistência (forte vs eventual)?

Question

Accepted Answer

**Modelos de consistência** definem garantias sobre quando e como atualizações de dados se tornam visíveis em um sistema distribuído — variando de **consistência forte** (todos veem os dados mais recentes imediatamente) até **consistência eventual** (atualizações se propagam ao longo do tempo). A escolha envolve trade-offs com disponibilidade e desempenho.

## Consistência forte vs eventual

```text
STRONG CONSISTENCY → every read returns the MOST RECENT write (all nodes agree immediately):
  ✓ simple to reason about; always correct/current data
  ✗ requires coordination → higher latency, lower availability (especially during partitions)
  → for: data that must be correct/current (financial balances, inventory, bookings)
EVENTUAL CONSISTENCY → updates propagate over time; reads MAY return stale data briefly,
  but all nodes CONVERGE eventually:
  ✓ high availability, low latency, scalable
  ✗ reads can be stale temporarily (must tolerate this)
  → for: data where brief staleness is OK (social feeds, likes, view counts, caches)
```

## O trade-off

```text
Consistency vs availability/performance (relates to CAP):
  → STRONGER consistency → more coordination → higher latency, lower availability
  → WEAKER (eventual) consistency → faster, more available, scalable, but stale reads
→ choose based on whether the data NEEDS to be immediately consistent for correctness.
```

## Outros modelos e nuance

```text
→ a SPECTRUM exists: read-your-writes, monotonic reads, causal consistency, etc.
→ Many systems offer TUNABLE consistency (choose per operation/query)
→ Use STRONG where correctness demands it; EVENTUAL where availability/scale matters and
  staleness is acceptable → often MIX within one system
```

## Por que isso importa

Compreender modelos de consistência é valioso porque **o trade-off entre consistência e disponibilidade/desempenho é fundamental para sistemas distribuídos**, por isso é importante conhecimento de design de sistemas.

Modelos de consistência definem quando atualizações de dados se tornam visíveis em um sistema distribuído, e a distinção chave — **consistência forte** (toda leitura retorna a escrita mais recente, todos os nós concordam imediatamente) versus **consistência eventual** (atualizações se propagam ao longo do tempo, leituras podem estar brevemente obsoletas mas convergem) — representa um trade-off fundamental.

Compreender isso é importante porque **consistência forte** fornece correção e simplicidade (dados sempre atuais) mas requer coordenação que aumenta latência e reduz disponibilidade (adequando-se a dados que devem estar corretos, como saldos financeiros, inventário e reservas), enquanto **consistência eventual** oferece alta disponibilidade, baixa latência e escalabilidade ao custo de obsolescência temporária (adequando-se a dados onde breve obsolescência é aceitável, como feeds sociais, likes e contadores de visualizações).

Compreender **o trade-off** (consistência mais forte significa mais coordenação, latência mais alta e menor disponibilidade; consistência mais fraca significa mais rápido, mais disponível e escalável mas com leituras obsoletas — relacionado ao teorema CAP) é o insight chave que guia escolher o modelo certo para cada caso de uso.

Compreender a **nuance** — que um espectro de modelos existe (leia-seu-próprio-write, consistência causal, etc.), que muitos sistemas oferecem **consistência ajustável** (escolhendo por operação), e que sistemas frequentemente **misturam modelos** (forte onde correção o exige, eventual onde disponibilidade e escala importam) — reflete compreensão sofisticada.

Escolher consistência apropriadamente é uma decisão chave de design afetando correção, disponibilidade e desempenho.

Já que o trade-off entre consistência e disponibilidade/desempenho é fundamental para sistemas distribuídos e escolher o modelo de consistência certo (forte vs eventual, frequentemente misto) afeta significativamente correção, disponibilidade e desempenho, e já que compreender os modelos e seus trade-offs é importante para projetar sistemas distribuídos e escolher bancos de dados, compreender modelos de consistência é valioso, conhecimento de design de sistemas praticamente relevante — um trade-off fundamental de sistemas distribuídos (consistência vs disponibilidade/desempenho), importante para escolher tratamento apropriado de dados baseado em necessidades de correção, e central para projetar sistemas distribuídos e selecionar bancos de dados com as garantias de consistência corretas.