Consistency Strong : Quand tu as besoin

Strong Consistency (linéarisation) est un modèle dans lequel toutes les opérations semblent être exécutées instantanément et de manière cohérente dans un ordre mondial cohérent avec le temps réel. L'utilisateur lira la dernière valeur confirmée et les deux clients parallèles ne se « dépasseront » pas logiquement.

La cohérence rigoureuse donne un modèle mental simple et protège les invariants rigides, mais nécessite une coordination (quorum/leader), ce qui augmente la latence et la sensibilité aux divisions du réseau.

1) Quand Strong - obligatoire

Finances et calculs

Bilan et pertes : le « double gaspillage » n'est pas acceptable.
Transferts et réciprocités : le même montant ne peut être effectué deux fois.

Inventaire et limites

Solde du produit/place de l'hôtel/billets : vous ne pouvez pas passer à des valeurs négatives.
Limites de transactions par unité de temps (limites de crédit, crédits API).

Unicité et intégrité

Identifiants/ID/règles de déduplication uniques.
Invariants au niveau du domaine : « Il doit y avoir un médecin ≥1 dans le département », « il ne peut y avoir> N tâches actives dans la file d'attente ».

Audit et journaux immuables

Les événements qui servent de source légale de vérité : l'ordre et la plénitude sont critiques.

Si la violation de l'invariant comporte des risques commerciaux inacceptables (perte d'argent, sanctions, perte de confiance) - choisissez Consistency Strong.

2) Ce qui est exactement « strict »

Linearizability (niveau opérationnel) : la lecture voit l'enregistrement le plus récent réussi ; les temps sont respectés.
Serializable (couche transactionnelle) : le résultat est équivalent à l'exécution des transactions en série (peut être fort, mais parfois implémenté sans ordre de temps réel rigide).
La différence importante est que Serializable protège contre les anomalies de niveau de transaction (phantom/write-skew), tandis que Linearizable protège contre l'instantanéité et l'ordre des opérations uniques. Vous avez souvent besoin des deux propriétés (par exemple, de l'argent dans la base de données + journal des événements).

3) Prix de la rigueur : PACELC et CAP

PACELC : lorsque vous divisez un réseau (P), vous devez choisir C (rigueur) ou A (disponibilité). Fort → CP : mieux vaut refuser ou bloquer qu'enfreindre un invariant. Quand il n'y a pas de séparation (EL), payer L - coordination/quorums augmente p95/p99.
Pratique : fort pour le « noyau des invariants », autour - projections rapides/caches avec eventual pour ne pas souffrir d'UX.

4) Comment atteindre la consistance forte

Leadership et quorum

Le seul leader accepte les enregistrements ; les lectures sont celles du leader ou du quorum des répliques.
Quorum 'W' pour l'écriture et 'R' pour la lecture avec 'R + W> N'augmente les chances de lire « dernier ».

Algorithmes de négociation

Raft/Paxos : logue de réplication, confirmations majoritaires, terme/index.
Réplication synchrone : l'enregistrement n'est confirmé qu'après la persistance au quorum.

Heures et ordre

TrueTime/Hybrid Logical Clocks (HLC) : limitez la taille de l'horloge pour une sérialisation globale sécurisée.
Fence-tokens/versioning : protection contre les leaders « matinaux » et split-brain.

Isolation des transactions

Serializable (SI + vérification de conflit/loki par prédicat) : protection contre phantom/write-skew.
Strict-serializable : Sérialisabilité + linéarisation par rapport au temps réel.

5) Multi-région : options et compromis

Leader mondial (CP)

Les enregistrements passent par une région leader ; lectures - caches/projections locales ou via le leader.
Les avantages : un modèle simple. Inconvénients : p95/RTT jusqu'au leader, avec P - verrouillage des enregistrements.

Leaders régionaux + quorum synchrone

Quorum géoraschiré de plusieurs régions ; chaque entrée attend des confirmations> 50 %.
Avantages : sans un seul « cou étroit », haute stabilité. Inconvénients : latence intercontinentale.

Geo-partitioning

Données « à domicile » pour la région (tenant/juridiction) ; opérations mondiales - via sagas/agrégats.
Avantages : faibles retards pour les enregistrements locaux. Inconvénients : planification des limites des données.

6) Personnalisation R/W et lectures

Entrées : 'W = majority' est la norme pour strong.

• « Le plus récent » est « R = majority » ou la lecture chez le leader.
• Pour réduire L - « stale-ok » lire des répliques pour les écrans secondaires (avec un marquage clair dans UX).
• Read-repair/lease read : optimisation sans perte de rigueur dans les locations courtes de leader.

7) Performance et UX

Latence : se concentrer sur la RTT entre le client et le leader/quorum (interrégionale des centaines de ms).
Modèle « write-strong, read-fast » : fort en écriture + cache/projection en lecture, avec RYW pour l'auteur.
Batch/paquets : regroupez les entrées, mais surveillez la latence de la queue.
Contours de dégradation : en cas d'incident - read-only, statuts honnêtes, interdiction des mutations dangereuses.

8) L'observabilité de la voie stricte

Métriques

p50/p95/p99 latitude : write-quorum, read-quorum, lectures de leadership.
Succès des quorums, répétitions/retours, changements de leader.
Patte de réplication (peu attendue, mais il est nécessaire de surveiller).
Proportion de lectures « steel » (si incluses).

Tracing

Spans : « acceptation par le leader », « réplication », « commit quorum ».
Теги: `term`, `leader_id`, `quorum_size`, `region`.

Alert

Croissance p95/p99, réélection fréquente du leader, quorum-timeouts, indicateurs split-brain.

9) Tests et chaos

Jepsen-like : séparations réseau, retards, drops, clock-skew.
Invariants de sécurité : impossibilité de double dépense/solde négatif/double réservation.
Leadership : refus du leader, réélections sous charge, jetons fence.
Cohérence de lecture : la lecture immédiatement après l'écriture doit voir « nouveau » (RYW/linearizable read).

10) Pleybooks d'incidents

Perte de quorum : commuter en read-only, alerter les clients, envoyer l'enregistrement à la région « à domicile » en présence de geo-partitioning.
Augmentation de la latence interrégionale : réduire temporairement le volume des enregistrements stricts (migration d'une partie des flux dans la file d'attente/projection), localiser le trafic.
Flap du leader : augmenter le temps des élections, vérifier les filets/dérives horaires/pauses GC.
Split-brain : activer les jetons fence/lease-check, arrêter les anciens leaders au niveau de l'opérateur.

11) Erreurs typiques

Exiger Strong « partout » : une explosion de latence et de coût au lieu de se concentrer sur les invariants.
Essayer d'être CA dans des divisions réelles : à l'instant P, le système fait encore des choix, souvent implicitement.
Dual-write dans différentes régions sans saga/coordinateur : fantômes et perte d'invariants.
Absence de RYW : l'utilisateur ne voit pas son entité qui vient d'être enregistrée est une perte de confiance.
Ignorer l'horloge : sans HLC/TrueTime-Borders, il est facile d'obtenir un temps « sautant » et des courses.
Pas de plan de dégradation : à P, des défaillances partielles chaotiques commencent.

12) Solutions rapides (recettes)

Paiements/bilans : leader + majority-quorum ; les transactions strict-serializable ; temps courts, panne dure sous P.
Réservation (places/slots) : write-strong via leader, lecture - cache avec RYW ; TTL-réserves + TCC.
Global SaaS : geo-partition par « tenant/region » ; opérations rigoureuses dans la région d'origine, rapports/recherches - par des projections.
Audit/journal : append-only journal CP ; les lectures peuvent être mises en cache, mais vérifiées par des points de contrôle.

13) Chèque-liste avant la vente

• Les invariants exigeant des effets forts sont délivrés ; le reste est en AR/projection.
• Mode choisi : leader unique/quorum interrégional/geo-partition.
• « W = majority », « R = leader 'majority » sont configurés pour les chemins critiques.
• Fourni RYW/monotonic pour UX ; les lectures « stale-ok » sont clairement marquées.
• Y compris les métriques de quorum, de lagunes, de latences ; alerte sur p95/p99 et réélection.
• Il y a un plan degrade : read-only, désactiver les mutations dangereuses, faire la queue pour « après la tempête ».
• Tests de chaos : divisions, clock-skew, refus du leader ; les invariants de sécurité ont été testés.
• Documentation des contrats : ce qui est strict, ce qui « peut être en retard », communication pour le produit/support.

Conclusion

Consistency Strong est un outil pour protéger la vérité lorsque l'erreur est inacceptable. Appliquez-la ponctuellement autour des invariants rigides, payant consciemment la coordination avec latence et disponibilité dans les tempêtes. Combiner : CP-noyau pour critique, AP-lecture et projection pour la vitesse. Avec la télémétrie, la dégradation et les tests appropriés, vous conserverez à la fois l'exactitude et l'expérience utilisateur.