Modelli di coerenza

La coerenza descrive i valori e l'ordine in cui i lettori vedono i cambiamenti competitivi. La scelta corretta è l'equilibrio tra rigidità degli invarianti, latenza, disponibilità e costo (PACELC). Di seguito è riportato un manuale pratico sui modelli e sulle loro applicazioni.

1) Modelli rigorosi

Linearizable (linearità, Strong)

È come se tutte le operazioni fossero eseguite istantaneamente in un unico ordine che rispetta il tempo reale.
I vantaggi sono un semplice modello mentale, sicuro per soldi e unicità.
Contro: quorum/leader di crescita p95/p99, soprattutto interregionale.
Bilanci, inventario con limiti rigidi, nomi/chiavi unici.

Sequential consistency

Tutti i flussi vedono lo stesso ordine delle operazioni, ma non l'ordine real-time. Leggermente più debole di linearizable, raramente esposto direttamente nei prodotti.

Serializable (serializzazione transazionale)

Equivale a un ordine transazionale sequenziale (anziché alle singole operazioni).
I vantaggi sono la correttezza di invarianti complessi a livello di query/tabella.
Meno: più costoso (blocchi/versioning/convalida dei conflitti).
Finoperazioni complesse, conteggi consistenziali, inventario.

Snapshot Isolation (SI)

Ogni transazione legge un'istantanea non modificabile nel tempo. i record sono in conflitto con «righe identiche», ma è possibile write skew.
I vantaggi sono letture veloci senza blocchi, rapporti stabili.
Contro: non serializzabile, trappola write skew (esempio: medici di turno).
Analisi, rapporti, la maggior parte CRUD senza invarianti rigidi.

2) Per-sessione e garanzie causali

Read-Your-Writes (RYW)

Il cliente, dopo la registrazione, la vede sempre nelle letture successive.
I vantaggi sono un buon UX (la forma è la conferma).
Contro - garanzia locale, non globale.

Monotonic Reads / Writes

Le letture non vengono reimpostate; i record di un singolo client vengono applicati nello stesso ordine in cui sono stati inviati.

Causal Consistency (causale)

Se l'operazione dipende da un'altra (A → B), tutti vedono A prima di B.
I vantaggi sono intuitivi per i CD, i commenti.
Meno - Più difficile da instradare e etichette di causalità (orologi vettoriali).
Le comunicazioni, la condivisione, i nastri degli eventi.

3) Modelli deboli e ibridi

Bounded Staleness

Le letture non possono essere più lunghe di un'altra versione.
I vantaggi sono il prevedibile UX, un buon compromesso interregionale.
Contro - Non protegge dai conflitti di scrittura.

Eventual Consistency

Con il tempo, tutte le copie convergono; ordine e ritardo non sono garantiti.
Vantaggi: minimo latitanza/costo, elevata disponibilità (PA).
Contro - È necessario un merge esplicito (CRDT/regole di dominio).
Cash, fidi, metriche, like, manuali critici.

4) Anomalie tipiche e che cosa significano

Dirty Read - Lettura di dati non memorizzati.
Read no-repeatable - La stessa lettura all'interno della transazione fornisce valori diversi.
Phantom: quando viene ricontrollata, viene visualizzata/scomposta la stringa corrispondente al predicato.
Write Skew (SI) - Due transazioni leggono un invariante intersecato e scrivono righe diverse, violando la condizione «deve essere ≥ 1».
Lost Update - La voce «esegue» le modifiche del concorrente.

5) Quorum e livelli di lettura/scrittura

Molti archivi consentono di impostare i livelli R/W (numero di repliche da leggere/scrivere).

Il quorum (R + W> N) fornisce «intersezione» e forti garanzie di lettura dell'ultimo record.
W = 1, R = 1 è un ritardo basso, ma sono possibili vecchi dati.
Sintonizzando: le operazioni critiche sono alta «W» (o leader), le altre sono basse «R» per la velocità.
Read-repair/Hinted handoff aiutano a ottenere coerenza sullo sfondo.

6) Orologio e ordine: come capiamo la causalità

Lamport clocks - Ordine parziale degli eventi.
Vettor clocks - Rileva la causalità, consente di rilevare i conflitti.
Approcci Hybrid/TrueTime - Limitano lo spostamento dell'orologio nel cluster per organizzare le transazioni e bound-staleness.
Versioning: 'variante/ts + actor'per merge; in CRDT - Semi-gruppi chiusi (commutabilità/idampotenza).

7) CRDT e merge di dominio

CRDT (tipi di dati convergenti/replicati) garantiscono la coesione senza coordinazione: G-Counter, OR-Set, LWW-Registrer, Map, varianti di testo OT/WOOT.
Quando è utile: like, molti tag, cestini, documenti.
Vincoli: creare una semantica di fusione corretta per un'entità di dominio specifica.

8) Collegamento CAP/PACELC

Modelli rigorosi (Linearizable/Serializable) in una regione multi-t-ROM con aumento della latenza (PACELC - Seleziona C e paghiamo L).
Modelli deboli/ibridi PA e/o basso L, ma serve merge/conflitto-risolutori.
Kernel CD per invarianti + proiezioni PA/cache per la lettura.

9) Selezione modello: foglio di assegno

1. Invarianti, cosa non si può violare? (unicità, equilibrio, limiti).
2. Regionalità: dove vengono scritte/lette? (locale/globale).
3. SLO di latenza: p95/p99 per percorsi critici?
4. Il prezzo del coordinamento è disposto a pagare con quorum interregionali?
5. C'è una merge determinata o serve un coordinatore?
6. Le aspettative UX: RYW/monotonic/causal sono importanti per il cliente?
7. Osservabilità: cosa si misura la lega/conflittualità/livello di obsolescenza?
8. Folback: cosa succede quando si divide una rete (P)? read-only/record/code locali?

10) Ricette veloci

Pagamento/saldo: Linearizable/Serializable, leader + quorum, brevi timeout; letture RYW.
Profili/fide: Causal/Bounded staleness + cache; CRDT per like/contatori RYW per l'autore.
Ricerca/analisi: SI/Read Committed, proiezioni asincroni, eventual per gli indici.
Global SaaS: Geo-partitioning; «registrazioni domestiche» - CD, report/directory - PA.
Modifica condivisa: causale/avvenual + CRDT/OT; Salva la cronologia.

11) Osservazione della coerenza

Le metriche sono «replication _ lag», «staleness _ age _ ms» (p50/p95/p99).
Conflittualità: percentuale di conflitti, tempo medio di risoluzione.
Quorum: successo dei quorum R/W, timeout dei percorsi interregionali.
Garanzia client: RYW/monotonic - etichette trace per sessione.

12) Errori tipici

Richiedere Strong «ovunque» senza una base di business è un'esplosione di latitanza e costo.
Dual-write in diverse regioni senza saghe/CRDT fantasma e perdita di invarianti.

Ignora i dati RYW/monotonicità in UX

Non monitorare l'obsolescenza della cache/proiezione di una soluzione temporanea.
Merge impreparato, perdite/prese di valori inaspettate.

13) Mini-riferimento architettura

Write-core (COP) - Leader, registrazioni quorum, SLO e timeout, registri.
Read-plane (AP) - Viste materializzate, cache TTL, read-repair.
Client: sticky-position/garanzie di sessione (RYW/monotonic), etichette di versione.
Conflitto-motore: CRDT/Regole di dominio, coda di risoluzione manuale.
Monitoraggio: lagi, conflitti, percentuali di letture obsolete.

Conclusione

Il modello di coerenza è un contratto di ingegneria tra dati, ritardo e disponibilità. Iniziate con invarianti e SLO, scegliete rigorosamente dove volete e più deboli dove potete, senza dimenticare le garanzie dei clienti, quorum, orologi e osservazione. Una combinazione adeguata di modelli offre scala, prevedibilità e sostenibilità senza sacrificare la verità aziendale e la fiducia degli utenti.