Quali sono i modelli di consistenza (forte vs eventuale)?

Question

Accepted Answer

I **modelli di consistenza** definiscono garanzie su quando e come gli aggiornamenti dei dati diventano visibili in un sistema distribuito — da **consistenza forte** (tutti vedono i dati più recenti immediatamente) a **consistenza eventuale** (gli aggiornamenti si propagano nel tempo). La scelta comporta compromessi con la disponibilità e le prestazioni.

## Consistenza forte vs eventuale

```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)
```

## Il compromesso

```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.
```

## Altri modelli e sfumature

```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
```

## Perché è importante

Comprendere i modelli di consistenza è prezioso perché **il compromesso tra consistenza e disponibilità/prestazioni è fondamentale nei sistemi distribuiti**, quindi è una conoscenza importante nel design dei sistemi.

I modelli di consistenza definiscono quando gli aggiornamenti dei dati diventano visibili in un sistema distribuito, e la distinzione chiave — **consistenza forte** (ogni lettura restituisce la scrittura più recente, tutti i nodi concordano immediatamente) rispetto a **consistenza eventuale** (gli aggiornamenti si propagano nel tempo, le letture possono essere brevemente non aggiornate ma convergono) — rappresenta un compromesso fondamentale.

Comprendere questo è importante perché la **consistenza forte** fornisce correttezza e semplicità (dati sempre attuali) ma richiede coordinamento che aumenta la latenza e riduce la disponibilità (adatto ai dati che devono essere corretti, come saldi finanziari, inventario e prenotazioni), mentre la **consistenza eventuale** offre alta disponibilità, bassa latenza e scalabilità al costo di una temporanea non-aggiornamento (adatto ai dati dove una breve non-aggiornamento è accettabile, come feed social, like e conteggi visualizzazioni).

Comprendere il **compromesso** (una consistenza più forte significa più coordinamento, latenza più alta e disponibilità inferiore; una consistenza più debole significa più veloce, più disponibile e scalabile ma con letture non aggiornate — in relazione al teorema CAP) è l'intuizione chiave che guida la scelta del modello giusto per ogni caso d'uso.

Comprendere la **sfumatura** — che esiste uno spettro di modelli (letture-delle-tue-scritture, consistenza causale, ecc.), che molti sistemi offrono **consistenza sintonizzabile** (scegliere per operazione), e che i sistemi spesso **mescolano modelli** (forte dove la correttezza lo richiede, eventuale dove la disponibilità e la scala contano) — riflette una comprensione sofisticata.

Scegliere la consistenza appropriatamente è una decisione di design chiave che influisce su correttezza, disponibilità e prestazioni.

Poiché il compromesso tra consistenza e disponibilità/prestazioni è fondamentale nei sistemi distribuiti e la scelta del giusto modello di consistenza (forte vs eventuale, spesso misto) influisce significativamente su correttezza, disponibilità e prestazioni, e poiché la comprensione dei modelli e dei loro compromessi è importante per progettare sistemi distribuiti e scegliere database, comprendere i modelli di consistenza è una conoscenza di system design preziosa e praticamente rilevante — un compromesso fondamentale nei sistemi distribuiti (consistenza vs disponibilità/prestazioni), importante per scegliere il trattamento dei dati appropriato in base alle esigenze di correttezza, e centrale per la progettazione di sistemi distribuiti e la selezione di database con le giuste garanzie di consistenza.