Théorème CAP (Consistency, Availability, Partition tolerance)

Le théorème CAP, formulé par Eric Brewer en 2000, est un principe fondamental de l'architecture des systèmes distribués. Il établit qu'un système de données distribué ne peut garantir simultanément que deux des trois propriétés suivantes : Cohérence (Consistency), Disponibilité (Availability) et Tolérance au partitionnement (Partition tolerance). Cette contrainte force les architectes à faire des choix stratégiques en fonction des besoins métier.

Fondements du théorème

• Cohérence (C) : tous les nœuds voient exactement les mêmes données au même moment, garantissant une lecture cohérente après chaque écriture
• Disponibilité (A) : chaque requête reçoit une réponse (succès ou échec) sans garantie que les données soient les plus récentes
• Tolérance au partitionnement (P) : le système continue de fonctionner malgré la perte de messages réseau ou la défaillance de certains nœuds
• Trade-off inévitable : en présence de partitionnement réseau (inévitable dans les systèmes distribués), il faut choisir entre cohérence et disponibilité

Avantages et implications stratégiques

• Cadre décisionnel clair pour l'architecture des bases de données distribuées et des systèmes à haute échelle
• Permet d'aligner les choix techniques avec les exigences métier (transactions bancaires vs réseau social)
• Facilite la compréhension des limites théoriques des systèmes distribués par les équipes techniques et métier
• Guide la sélection de technologies adaptées (SQL vs NoSQL, MongoDB vs Cassandra, etc.)
• Optimise les coûts d'infrastructure en évitant les sur-ingénieries inutiles pour des garanties non requises

Exemple concret : choix CP vs AP

Considérons deux cas d'usage représentatifs illustrant les choix CP (Cohérence + Partition tolerance) et AP (Availability + Partition tolerance) :

// Système CP : Transactions bancaires
// Privilégie la cohérence, accepte l'indisponibilité temporaire
class BankingSystem {
  async transferFunds(from: string, to: string, amount: number) {
    // Utilise un consensus distribué (Paxos, Raft)
    const lock = await this.acquireDistributedLock([from, to]);
    
    try {
      // Garantit la cohérence totale entre tous les nœuds
      await this.debitAccount(from, amount);
      await this.creditAccount(to, amount);
      await this.commitTransaction();
    } catch (error) {
      // En cas de partition réseau : REFUSE la transaction
      // Préfère l'indisponibilité à l'incohérence
      throw new Error('Transaction unavailable due to network partition');
    } finally {
      await lock.release();
    }
  }
}

// Système AP : Réseau social
// Privilégie la disponibilité, accepte la cohérence éventuelle
class SocialMediaSystem {
  async postStatus(userId: string, content: string) {
    // Écrit immédiatement sur le nœud local
    const post = await this.localNode.createPost({
      userId,
      content,
      timestamp: Date.now()
    });
    
    // Réplication asynchrone vers autres nœuds
    this.replicateAsync(post).catch(err => {
      // Les autres utilisateurs verront le post avec un léger délai
      // (cohérence éventuelle / eventual consistency)
      this.scheduleRetry(post);
    });
    
    // Retourne immédiatement : toujours disponible
    return { success: true, postId: post.id };
  }
}

Mise en œuvre du théorème CAP

1. Analyser les exigences métier : identifier si la cohérence stricte ou la disponibilité maximale est prioritaire
2. Accepter que la tolérance au partitionnement est non négociable dans les systèmes cloud/distribués modernes
3. Choisir le profil CP (HBase, MongoDB en mode strict, systèmes financiers) ou AP (Cassandra, DynamoDB, Riak)
4. Implémenter des mécanismes de cohérence éventuelle pour les systèmes AP (versioning, résolution de conflits)
5. Monitorer les métriques clés : latence de réplication, taux de conflits, temps d'indisponibilité
6. Documenter explicitement le choix CAP dans l'architecture pour éviter les malentendus avec les parties prenantes
7. Tester les scénarios de partition réseau (chaos engineering) pour valider le comportement du système

Outils et technologies associés

• Systèmes CP : PostgreSQL (avec réplication synchrone), HBase, MongoDB (WriteConcern majority), Consul, etcd, ZooKeeper
• Systèmes AP : Cassandra, DynamoDB, Riak, CouchDB, Voldemort
• Algorithmes de consensus : Paxos, Raft, Byzantine Fault Tolerance pour garantir la cohérence
• Outils de test : Jepsen (vérification formelle des propriétés CAP), ToxiProxy (simulation de partitions réseau)
• Frameworks de résolution de conflits : CRDTs (Conflict-free Replicated Data Types) pour la cohérence éventuelle

Comprendre et appliquer correctement le théorème CAP permet d'éviter des erreurs d'architecture coûteuses. En alignant les choix techniques sur les priorités métier réelles plutôt que sur des garanties théoriques inutiles, les organisations réduisent la complexité opérationnelle, optimisent les coûts d'infrastructure et améliorent l'expérience utilisateur. L'essentiel est de reconnaître qu'il n'existe pas de solution universelle : chaque système distribué doit faire des compromis explicites et documentés.