Article FRANCHEMENT intéressant sur le théorème CAP, qui est souvent mal compris. Il m'a ouvert les yeux alors que je pensais le maitriser.
Ceci dit, les conclusions restent un peu les mêmes, mais ce qui est entendu dans les différents concepts est différent de ce que j'avais compris intuitivement (surtout sur Partition Tolerance)

Pour rappel, le théorème CAP parle de système distribués et de scalabilité :
« Dans un système distribué (reposant sur des données partagées) vous ne pouvez conserver que deux des trois propriétés suivantes :

• [en:Consistency] Consistence ;
• [en:Availability] Disponibilité ;
• [en:Partition Tolerance] Résistance au partitionnement »

Shorter : la dernière propriété n'indique pas que le système est distribué (c'est H0, l'hypothèse de base) mais l'état d'un système distribué dans lequel certains nœuds deviennent séparés (par coupure réseau, serveur en panne, etc.) d'autres nœuds. D'où l'existence de "partitions"

Finalement, ce théorème (formellement Brewer' Theorem) indique que, dans un système distribué, en cas de partionnement, il faut choisir la stratégie transactionnelle vis-à-vis des clients :

• soit refuser de répondre pour ne pas donner une réponse incohérente ou corrompre les données ;
• soit accepter de corrompre des données (éventuellement temporairement) en écriture ou renvoyer des données anciennes (inconsistantes).

Une dernière notion enfin.
Maintenir soit A soit C est élitiste, et en pratique on peut trouver un continuum de stratégies. D'où les notions de :

• [en:Yield] Rendement : c'est le pourcentage de requêtes qui seront complètement (completness + correctness) exécutées ;
• [en:Harvest] Moisson : c'est la proportion de données complètes traitées sur une requête.

C'est très intéressant de travailler avec ces deux notions, notamment pour décrire des SLA. Parce que, par exemple, le "uptime" ne reflète pas vraiment la garantie offerte : les coupures lors des creux n'ont pas le même impact que lors des pics.