La PAC et les compromis techniques

La PAC affirme : dans les conditions de séparation du réseau (Partition, P), le système distribué ne peut garantir simultanément une forte cohérence (Consistency, C) et une disponibilité (Availability, A). Si P est disponible, vous devez choisir soit CP, soit AP. En l'absence de divisions, la restriction n'est pas valable, mais d'autres compromis apparaissent - principalement le retard (latency) et le coût.

L'ingénierie pratique dépasse les limites de la PAC : PACELC est important (si P - on choisit C ou A ; sinon - nous choisissons entre Latinity et Consistency), les modèles de cohérence, les SLA/SLO, les yuskais et les risques commerciaux.

1) Définitions de base (sans philosophie)

Cohérence (C) : tous les clients voient le même résultat « comme si » les opérations ont été effectuées de façon séquentielle (linéarisation/consistance forte).
Disponibilité (A) : Chaque requête à un nœud non tombé se termine par une réponse dans un délai raisonnable, même en cas de séparation.
Séparation (P) : perte ou dégradation significative de la communication entre nœuds/grappes régionales ; essentiellement - « inévitablement » à grande échelle.
PACELC : à P, on choisit C ou A ; else (quand P n'est pas là) on choisit L (faible latence) ou C (forte cohérence).

2) L'image intuitive de la sélection

CP (la cohérence est plus importante) : lors de la séparation, une partie des demandes est rejetée/bloquée afin de ne pas perturber les invariants. Convient pour l'argent, les transactions, la comptabilité des soldes.
AP (accessibilité plus importante) : nous répondons toujours, mais nous admettons un désaccord temporaire, puis nous saisissons les conflits (CRDT/règles Merge). Convient pour les sodas, les compteurs de « j'aime », les profils cachés.
CA (simultanément C et A) : possible uniquement en l'absence de P - c'est-à-dire tant que le réseau est en bonne santé. Dans l'exploitation réelle, « CA » est un état temporaire, pas une propriété de conception.

3) PACELC : on n'oublie pas le retard

• Forte consistance entre les régions = quorums intercontinentaux ⇒ des dizaines à des centaines de ms par p95.
• Lectures locales (faible L) = garanties plus faibles (read-my-writes, staleness bounded, eventual).
• PACELC aide à expliquer pourquoi « rapidement et strictement » globalement est rare : la lumière n'est pas instantanée et les quorums se développent avec le pliage du réseau.

4) Modèles de cohérence (spectre rapide)

Linearizable/Strong : Comme un ordre séquentiel.
Serializable : équivalent à un ordre de transaction séquentiel (au-dessus du niveau d'enregistrement).
Read-your-writes/Monotonic reads : le client, après son propre enregistrement, lit une nouvelle valeur.
Bounded staleness : les lectures ne sont pas plus tardives que N versions/ Δ t.
Consistency eventual : avec le temps, toutes les copies convergent ; les conflits doivent être résolus.

5) Modèles CP et AP dans les produits et protocoles (conceptuellement)

Approches CP : journal de quorum/leadership (Raft/Paxos), transactions rigoureuses, localisation mondiale du leader, réplication synchrone. Prix - refus d'une partie des demandes à P et augmentation des retards.
Approches AP : multi-maître/multi-leader, CRDT, distribution gossip, réplication asynchrone, résolution de conflit (LWW, horloge vectorielle, fonctions de mesure de domaine). Le prix est un désaccord temporaire et la complexité des règles de domaine.

6) Compromis dans la multi-région

Leader mondial (CP) : logique simple, mais les régions « lointaines » paient la latence ; en P - verrouillage des enregistrements.
Leaders locaux + asynchrones (AP) : écriture rapide localement, puis réplication ; les changements conflictuels exigent une merge.
Géo-partitioning : les données « vivent » plus près de l'utilisateur/juridiction ; la région croisée n'est que des agrégats.
Dual-write est interdit sans saga/CRDT : sinon on obtient des fantômes et des doubles débits.

7) Invariants d'ingénierie et solutions d'affaires

D'abord invariants : ce qui ne peut jamais être perturbé (double débit, solde négatif, unicité de la clé), et ce qui « survit » à l'eventual (compteur de vues, recommandations).

• Invariant « rigide » → CP pour les opérations concernées.
• L'invariant est « doux » → AP, suivi d'un arrachage.

8) Techniques d'atténuation des compromis

Cache et CQRS : lectures par le biais d'un cache/projection proche (AP), écritures dans un journal rigoureux (CP).
RPO/RTO comme langage de compromis : combien de données peuvent être perdues (RPO) et comment récupérer rapidement (RTO).
ID et horloge cohérentes : Timestamps monotones (approches hybrides/TrueTime), ULID/Snowflake.
Sagi/TSS : compensation des entreprises au lieu de blocages mondiaux.
CRDT et mesure de domaine : pour les collections, les compteurs, les « dernières victoires ».
Bounded staleness : équilibre UX et précision.

9) Observation, SLO et gestion des incidents

SLO par latence (p50/p95/p99) séparément pour les lectures/enregistrements et les régions.
SLO sur l'accessibilité en tenant compte du faussaire de la région.
Lag réplication/conflit : proportion de conflits, temps de résolution moyen.
Alert par le signe P : sursaut du temps des canaux interrégionaux, augmentation des erreurs de quorum.
Degrade-plans : read-only mode, service local suivi de merge, désactivation des fonctionnalités « chères ».

10) Chèque-liste de sélection de stratégie

1. Quels invariants ne peuvent être violés ? Qu'est-ce qui permet eventual ?
2. Ai-je besoin d'un enregistrement croisé à faible latence ?
3. Quels sont les SLO cibles (latence/disponibilité) et le coût (egress/réplication) ?
4. Est-ce que vous admettez manual merge ou seulement un automate (CRDT/règles) ?
5. Quel est le profil de défaillance du réseau : fréquence, durée, radius blast ?
6. Y a-t-il une localisation légale des données (résidence) ?
7. Quel modèle de cohérence est acceptable pour chaque type de données/activité ?
8. Comment allez-vous observer : les lagunes, les conflits, l'état des quorums ?
9. Que fait le système à P : bloquer, dégrader, séparer le trafic ?
10. Quel est le plan de récupération et de rapatriement des données après P ?

11) Erreurs typiques

La poursuite de « CA pour toujours ». Au premier, P devra choisir - mieux à l'avance.
Multi-maître global sans règles de merge. Les conflits « mangent » les données et la confiance.
Une forte consistance « partout ». Les quorums excédentaires frappent p95/p99 et le budget.
Dual-write sans transactions/saga. Invariants et fantômes perdus.
Ignorer PACELC. En temps de paix, la latence souffre, l'accessibilité dans la tempête.
Télémétrie zéro des conflits et des retards. Les problèmes ne sont visibles que par l'utilisateur.

12) Recettes rapides

Paiement/solde : Stockage CP avec quorums ; les enregistrements uniquement par l'intermédiaire du leader ; les lectures peuvent être mises en cache, mais dans les UX critiques, c'est read-your-writes.
Contenu/Fid : Réplication AP + CRDT/règles Merge ; à P - servir localement, puis coller.
Global SaaS : geo-partitioning par « tenant/region » ; opérations rigoureuses dans la région « maison » (CP), rapports/recherche - par des projections asynchrones (AP).
Signal de temps réel : Anycast/edge + bus AP ; les commandes critiques passent par le canal confirmé (CP).
Audit/journal : la seule source de vérité (append-only) avec les garanties CP, autour - caches et projections.

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

Write-core (CP) : leader + réplication quorum, invariants rigoureux, sagas pour effets interservices.
Read-plane (AP) : représentations matérialisées, caches, index de recherche, mise à jour asynchrone.
Géo-routage : les utilisateurs entrent dans la région « maison » ; avec P, mode local + réplication ultérieure.
Moteur de conflit : CRDT/règles ; Journal des conflits et moyens de résolution manuelle.
Observabilité : Tracing quorum, lagune, carte des incidents du réseau.

14) Mathématiques pratiques des retards (estimation simple)

Optique ≈ 5 ms pour 1000 km (RTT encore plus). Quorum intercontinental → p95 facilement> 150-250 ms.
Tout « Global Strong » pour l'enregistrement est une demande coûteuse. Si UX nécessite <100-150 ms, pensez aux conséquences locales write-home + asynchrones.

15) Politiques en cas de division

Chemin CP : bloquer les enregistrements en dehors du quorum ; inclure la lecture seule ; donner des statuts honnêtes à l'utilisateur.
Chemin AP : servir localement ; marquer les versions ; lors de la restauration - merge déterministe ; les conflits font le tour de l'analyse.

Conclusion

La PAC n'est pas un dogme, mais un rappel : les divisions du réseau sont inévitables et le projet doit choisir à l'avance ce qu'il faut sacrifier dans une tempête - l'accessibilité ou la stricte cohérence. PACELC ajoute un axe de retard clé par temps clair. Combinez les stratégies : gardez le noyau CP là où les invariants sont sacrés et le plan AP là où la vitesse et la résilience sont plus importantes. Mettez en place la télémétrie, les plans de dégradation et les processus de merge - et le système conservera à la fois les données et la confiance de l'utilisateur.