Théorème CAP : décider ce que l’application fait pendant une coupure

Un service de réservation ne peut plus joindre la machine qui tient le stock. Il peut attendre, refuser la réservation ou accepter une demande sans la confirmer. CAP aide à comprendre ce choix : pendant une coupure, garantir une réponse à chaque opération peut empêcher de garantir que toutes les réponses respectent le même état des données. La décision dépend de ce que l'opération promet au client.

Le théorème fixe une limite aux garanties simultanées

CAP concerne un système dont plusieurs machines partagent des données. Il montre une impossibilité : face à certaines pertes de communication, le système ne peut pas garantir à la fois la cohérence stricte des données et une réponse à chaque demande reçue par une machine qui fonctionne.

La preuve de Gilbert et Lynch, publiée en 2002, donne un sens précis aux trois lettres :

• C, cohérence. Les opérations paraissent agir sur une seule copie. Une lecture commencée après une écriture terminée doit voir cette écriture, ou une plus récente. Cette garantie s'appelle la linéarisabilité.
• A, disponibilité. Chaque demande reçue par une machine qui fonctionne finit par recevoir une réponse conforme à l'opération. La définition ne donne pas de délai maximal.
• P, tolérance aux partitions. Le système doit composer avec la perte de messages entre certaines machines.

L'exemple des deux caisses et du dernier produit en stock détaille ces notions. Pour les appliquer, il faut surtout préciser la garantie attendue de chaque opération.

Afficher un stock et confirmer une réservation n'engagent pas la même promesse

Une page peut afficher un stock récemment calculé en indiquant l'heure de mise à jour. Une confirmation de réservation engage davantage : le client s'attend à ce qu'un exemplaire lui soit réellement attribué.

Pendant une coupure, ces opérations peuvent donc adopter des comportements différents :

La troisième ligne change le service proposé : une demande en attente ne vaut pas réservation garantie. Il faut que le message présenté au client rende cette différence visible.

Je préfère décrire ces comportements avant d'attribuer une étiquette à l'architecture. L'équipe peut alors vérifier, par un test de coupure, que chaque opération tient la promesse annoncée.

La formule « deux sur trois » masque ce travail de conception

Le raccourci laisse penser que cohérence, disponibilité et partitions sont trois options comparables. Pourtant, renoncer à traiter les partitions ne rend pas le réseau fiable : cela revient à limiter les conditions dans lesquelles vous garantissez le fonctionnement.

Eric Brewer est revenu sur cette formulation en 2012. Il souligne notamment que le choix peut varier selon l'opération ou la donnée. Une application n'a donc pas besoin d'adopter la même réponse à une panne pour tous ses usages.

Les appellations « CP » et « AP » désignent couramment une préférence pour la cohérence ou la disponibilité sous partition. Elles restent insuffisantes pour comprendre un produit réel. Il faut connaître les opérations concernées, les modes de panne considérés et les garanties exactes.

Martin Kleppmann critique précisément ces classifications : les définitions du théorème ne couvrent pas tous les aspects qui intéressent les utilisateurs d'une base de données. Le comportement documenté et testé apporte une information plus utile.

Le réseau peut être trop lent sans être physiquement coupé

Quand une réponse tarde, le client ignore parfois si le serveur est arrêté, si le message a été perdu ou si le traitement continue. Un délai d'attente dépassé, ou timeout, indique cette incertitude ; il ne permet pas à lui seul d'en connaître la cause.

En pratique, vous fixez une durée au-delà de laquelle l'opération ne peut plus attendre. À cet instant, elle doit disposer d'un comportement prévu : échouer, présenter une information ancienne ou enregistrer une demande à reprendre.

Plusieurs incidents peuvent provoquer ce besoin : une liaison interrompue, un service externe indisponible ou une file de messages qui n'avance plus. Il reste nécessaire de les distinguer pour les réparer.

De même, un doublon ou un message reçu dans le désordre n'est pas, à lui seul, la preuve d'une partition. Et une copie de lecture mise à jour volontairement en différé peut être en retard alors que tout fonctionne normalement. Ces situations demandent des protections différentes.

Hors panne, la coordination a encore un coût

Lorsque les communications fonctionnent, CAP n'impose pas de choisir entre cohérence et disponibilité. Pour autant, maintenir plusieurs copies à jour demande des échanges, et ces échanges prennent du temps.

Daniel Abadi a proposé PACELC en 2010, puis l'a développé en 2012, pour distinguer deux situations. Pendant une partition, le compromis porte sur disponibilité et cohérence. En fonctionnement normal, il porte notamment sur le délai de réponse et la cohérence.

Une lecture locale peut répondre vite sans attendre la dernière mise à jour. Une lecture qui exige de vérifier plusieurs machines attend leur coordination. Cette décision existe même sans incident réseau.

Écrire le comportement attendu pour chaque opération

Pour une réservation, un paiement ou un affichage, notez les informations qu'il faut obtenir et le délai acceptable. Précisez ensuite ce que le client reçoit si ces informations restent inaccessibles.

Le travail continue à la reconnexion : les demandes en attente doivent être traitées, les copies rapprochées et les promesses incompatibles résolues. L'article sur la réconciliation après une coupure traite cette reprise. Un mode dégradé n'est utilisable que si le service sait aussi en sortir.

Sources

• S. Gilbert & N. Lynch, Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services, ACM SIGACT News, 2002.
• E. Brewer, CAP Twelve Years Later: How the "Rules" Have Changed, IEEE Computer, 2012.
• D. Abadi, Problems with CAP, and Yahoo's little known NoSQL system, DBMS Musings, 2010.
• D. Abadi, Consistency Tradeoffs in Modern Distributed Database System Design, IEEE Computer, 2012.
• M. Kleppmann, A Critique of the CAP Theorem, 2015.
• M. Kleppmann, Please stop calling databases CP or AP, 2015.