Modèles de cohérence

La cohérence décrit les valeurs et l'ordre dans lesquels les lecteurs voient les changements concurrentiels. Le bon choix du modèle est l'équilibre entre la rigueur des invariants, la latence, l'accessibilité et le coût (PACELC). Voici un manuel pratique sur les modèles et leurs applications.

1) Modèles « stricts »

Linearizable (linéarisation, Strong)

C'est comme si toutes les opérations étaient effectuées instantanément dans un ordre unique qui respecte le temps réel.
Avantages : un modèle mental simple, sûr pour l'argent et l'unicité.
Contre : quorum/leader → croissance p95/p99, surtout interrégionale.
Yuskais : bilans, inventaire avec limites strictes, noms/clés uniques.

Sequential consistency

Tous les flux voient le même ordre d'opération, mais l'ordre real-time n'est pas obligatoire. Un peu plus faible que linearizable, rarement exposé directement dans les produits.

Serializable (sérialisation transactionnelle)

Équivalent à un ordre de transaction séquentiel (et non à des opérations individuelles).
Avantages : exactitude des invariants complexes au niveau des requêtes/tables.
Inconvénients : plus coûteux (verrouillage/versioning/validation des conflits).
Yuskeis : datations complexes, recalculs constants, inventaire.

Snapshot Isolation (SI)

Chaque transaction lit un instantané immuable dans le temps ; les enregistrements sont en conflit sur « les mêmes lignes », mais un skew write est possible.
Avantages : lectures rapides sans verrous, rapports stables.
Inconvénients : non sérialisable, piège à skew write (exemple : médecins de service).
Yuskais : analyste, rapports, la plupart des CRUD sans invariants rigides.

2) Per-session et garanties causales

Read-Your-Writes (RYW)

Le client après son enregistrement la voit toujours dans les lectures suivantes.
Avantages : bon UX (formulaire → confirmation).
Inconvénients : garantie locale, pas globale.

Monotonic Reads / Writes

Les lectures ne « reculent » pas ; les dossiers d'un client sont appliqués dans le même ordre que ceux qui ont été envoyés.

Consistance causale (causale)

Si l'opération dépend de l'autre (A → B), tout le monde voit A avant B.
Avantages : intuitif pour les soz-fid, les commentaires.
Inconvénients : le routage et les étiquettes de causalité (horloge vectorielle) sont plus difficiles.
Yuskeis : communications, co-édition, flux d'événements.

3) Modèles faibles et hybrides

Bounded Staleness

Les lectures ne peuvent pas dépasser Δ t ou N versions.
Avantages : UX prévisible, bon compromis interrégional.
Inconvénients : ne protège pas contre les conflits d'enregistrement.

Eventual Consistency

Avec le temps, toutes les copies convergent ; l'ordre et le délai ne sont pas garantis.
Avantages : latence minimale/coût, haute disponibilité (AP).
Inconvénients : vous avez besoin d'un merge explicite (CRDT/règles de domaine).
Yuskeis : caches, fids, métriques, j'aime, nen manuels critiques.

4) Anomalies typiques et ce qu'elles signifient

Dirty Read : lecture de données non disponibles.
Lecture non reproductible : la même lecture dans une transaction donne des valeurs différentes.
Phantom : une chaîne qui correspond au prédicat apparaît/disparaît lors de la requête répétée.
Write Skew (en SI) : deux transactions lisent l'invariant croisé et écrivent des lignes différentes, violant la condition « le total doit être de ≥ 1 ».
Lost Update : l'entrée « freine » le changement de concurrent.

5) Quorums et niveaux de lecture/écriture

De nombreux magasins vous permettent de définir les niveaux « R »/« W » (nombre de répliques en lecture/écriture).

Le quorum (R + W> N) donne une « intersection » et de fortes garanties de lecture du dernier enregistrement.
W = 1, R = 1 → faible latence, mais d'anciennes données sont possibles.
Tuning : opérations critiques - haut « W » (ou leader), les autres sont bas « R » pour la vitesse.
Read-repair/Hinted handoff aident à obtenir la cohérence dans le fond.

6) Horloge et ordre : Comment « comprendre » la causalité

Lamport clocks : ordre partiel des événements.
Clocks vectoriels : capturent la causalité, permettent de détailler les conflits.
Approches hybrides/TrueTime : limitent la dispersion des heures dans le cluster pour organiser les transactions et bound-staleness.
Versioning : 'version/ts + actor' pour merge ; dans le CRDT, les demi-groupes fermés (commutation/idempotence).

7) CRDT et domaine merge

Les CRDT (Convergent/réplicable Data Types) garantissent une convergence sans coordination : G-Counter, OR-Set, LWW-Register, Map, texte OT/WOOT options.
Quand c'est utile : j'aime, beaucoup de tags, des paniers, des documents.
Restrictions : proposer une sémantique de « fusion » correcte pour une entité de domaine spécifique.

8) Communication avec la PAC/PACELC

Modèles rigoureux (Linearizable/Serializable) dans la multi-région → CP avec augmentation de latence (PACELC : nous choisissons C et payons L).
Modèles faibles/hybrides → AP et/ou bas L, mais besoin de merge/conflit-résolve.
Hybride : Noyau CP pour invariants + projection AP/cache pour les lectures.

9) Sélection du modèle : chèque-feuille

1. Invariants : Que ne peut-on pas violer ? (unicité, équilibre, limites).
2. Régionalité : Où sont effectués les enregistrements/lectures ? (local/global).
3. SLO par latence : p95/p99 pour les voies critiques ?
4. Prix de la coordination : prêts à payer par quorum interrégional ?
5. Conflits : avez-vous une merge déterministe ou avez-vous besoin d'un coordonnateur ?
6. Les attentes UX : RYW/monotonic/causal pour le client sont-elles importantes ?
7. Observabilité : en quoi mesurez-vous la lame/conflit/degré d'obsolescence ?
8. Folbacky : que se passe-t-il lorsque le réseau est divisé (P) ? read-only/enregistrement local/files d'attente ?

10) Recettes rapides

Paiement/solde : Linearizable/Serializable, leader + quorum, temps courts ; lectures RYW.
Profils/Fid : Casal/Bounded staleness + cache ; CRDT pour les likes/compteurs ; RYW pour l'auteur.
Recherche/analyse : SI/Read Committed, projections asynchrones, eventual pour les index.
Global SaaS : Geo-partitioning ; « dossiers à domicile » - CP, rapports/catalogues - AP.
Co-édition : Causal/eventual + CRDT/OT ; préserver l' « histoire ».

11) Observabilité de la cohérence

Lag métrique : 'replication _ lag', 'staleness _ age _ ms' (p50/p95/p99).
Conflit : proportion de conflits, temps moyen de résolution.
Quorum : Succès des 'R/W' quorum, temps des voies interrégionales.
Garantie client : RYW/monotonic - tags par session.

12) Erreurs typiques

Exiger Strong « partout » sans base d'affaires → une explosion de latence et de coût.
Dual-write dans différentes régions sans saga/CRDT → fantômes et perte d'invariants.
Ignorer RYW/monotonicité dans UX → la « disparition » des données qui viennent d'être envoyées.
Ne pas suivre l'obsolescence des caches/projections → les divergences « éternelles ».
Merge mal conçu → pertes/prises inattendues de valeurs.

13) Mini-référence de l'architecture

Write-core (CP) : leader, quorum records, SLO et timeouts, magazines.
Read-plane (AP) : représentations matérialisées, TTL-cache, read-repair.
Client : sticky-session/session garanties (RYW/monotonic), étiquettes de version.
Moteur de conflit : CRDT/règles de domaine, file d'attente de résolution manuelle.
Surveillance : lagunes, conflits, proportion de lectures obsolètes.

Conclusion

Un modèle de cohérence est un contrat d'ingénierie entre les données, la latence et la disponibilité. Commencez par les invariants et les SLO, choisissez strictement où vous voulez et plus faible où vous pouvez, sans oublier les garanties clients, les quorums, les heures et l'observation. Une combinaison compétente de modèles donne l'échelle, la prévisibilité et la durabilité - sans sacrifier la vérité commerciale et la confiance des utilisateurs.