Partition Tolerance (CAP)

Quand le réseau se coupe entre nos nœuds, on continue de servir. Reste à décider : cohérence ou disponibilité, pas les deux.

Problème

Tout système distribué subit tôt ou tard des partitions réseau : panne d'un câble inter-DC, congestion, mise à jour de switch. Pendant une partition, deux moitiés du cluster ne peuvent plus se synchroniser. Le théorème CAP de Brewer (PODC keynote 2000) énonce qu'on doit choisir : cohérence forte (toutes les lectures voient la dernière écriture) ou disponibilité (toutes les requêtes obtiennent une réponse) — pas les deux quand P est présent.

Forces

• Les partitions réseau existent en production, indépendamment du soin apporté à l'infrastructure.
• Refuser les écritures pendant une partition (CP) gèle les utilisateurs côté minorité.
• Accepter les écritures partout (AP) crée des conflits à réconcilier.
• La latence inter-DC (ms à 10s) influe sur la décision pratique : c'est PACELC plus que CAP.
• Kleppmann (2015) critique CAP : le « C » n'est pas serializability, le « A » suppose un timeout infini ; la matrice 2x2 simplifie trop.

Solution

Concevoir explicitement la réponse du système en partition : CP (Spanner, CockroachDB, HBase, etcd) suspend les écritures sur la minorité pour préserver la cohérence linéarisable ; AP (Cassandra, Dynamo, Riak) accepte les écritures partout et réconcilie ensuite (CRDTs, last-write-wins, vector clocks). Le choix dépend du métier : un système bancaire préfère CP, un panier d'achat préfère AP. Une variante moderne (PACELC d'Abadi 2012) ajoute le trade-off latence/cohérence en l'absence de partition.

Structure

Cluster intact (P=0):
  Writes commit on majority → C and A both hold

Network partition splits cluster into {A,B} | {C,D,E}:

  CP design (Raft, Spanner):
    Side {A,B}  ──► reject writes (no quorum)
    Side {C,D,E}──► accept writes (has quorum)
    On heal: side {A,B} catches up the log
    => no divergence, but partial unavailability

  AP design (Dynamo, Cassandra):
    Side {A,B}  ──► accept writes locally
    Side {C,D,E}──► accept writes locally
    On heal: conflict resolution (LWW or CRDT)
    => always available, may surface stale reads

Implémentation EDI

Un hub EDI multi-région doit choisir en cas de partition transatlantique entre les datacenters Europe et US : (a) CP — on suspend les écritures côté US, les commandes US se mettent en queue locale jusqu'au retour du lien (RPO 0, RTO ~minutes) ; (b) AP — chaque DC continue à recevoir des commandes ; au retour du lien, on réconcilie. La règle EDI usuelle est CP pour la facturation (cohérence fiscale stricte), AP pour le tracking d'expédition (la donnée tracking n'a pas de contrainte d'unicité globale).

Anti-patterns

• Prétendre faire CA — c'est une fausse promesse ; toute partition force CP ou AP.
• Choix CAP fait par défaut sans analyse métier — incidents incompris en production.
• Croire que CAP est la fin du débat — PACELC ajoute latence vs cohérence en marche normale.
• Mélanger sémantiques CP et AP dans le même système sans le rendre explicite — chaos lors d'une partition.
• Tests de chaos sans test de partition — la résilience n'est pas validée.

Patterns liés

• Consensus (Raft) — choix CP typique.
• Sharding — limite la portée des partitions à des sous-ensembles.
• Circuit Breaker — mécanisme de protection en cas de partition.
• Bulkhead — isole les pools pour réduire l'impact d'une partition.

Sources

• Brewer E. — Towards Robust Distributed Systems, PODC keynote 2000.
• Kleppmann M. — Please stop calling databases CP or AP, 2015. martin.kleppmann.com — Please stop calling databases CP or AP
• Abadi D. — Consistency Tradeoffs in Modern Distributed Database System Design, IEEE Computer 2012 (PACELC).
• Kleppmann M. — Designing Data-Intensive Applications, O'Reilly 2017, chap. 8 « The Trouble with Distributed Systems », chap. 9.