Expliquez le théorème CAP à un chef de produit

Très bien, parlons du théorème CAP. C'est un concept fondamental dans les systèmes distribués qui sera vraiment important pour nos discussions architecturales à venir. Considérez-le comme un principe directeur qui nous aide à comprendre les compromis inhérents lors de la conception de systèmes qui stockent des données sur plusieurs machines. Le théorème CAP stipule qu'un magasin de données distribué ne peut garantir que deux des trois propriétés à tout moment : la Cohérence, la Disponibilité et la Tolérance aux Partitions. Décomposons ce que chacun de ces termes signifie en termes pratiques : 1. **Cohérence (C) :** Imaginez que vous mettiez à jour une information, comme changer votre photo de profil. Un système cohérent garantit que *tous* ceux qui essaient de voir votre photo de profil voient immédiatement la *nouvelle*. Il n'y a pas de période où certains utilisateurs voient l'ancienne photo et d'autres la nouvelle. Tous les utilisateurs voient les mêmes données les plus récentes en même temps, quelle que soit la partie du système avec laquelle ils interagissent. 2. **Disponibilité (A) :** Un système disponible signifie que chaque requête que vous lui envoyez reçoit une réponse. Le système est toujours opérationnel et prêt à servir les requêtes. Vous n'obtenez jamais un message d'erreur indiquant "système indisponible" ou ne subissez jamais de délai d'attente. Il ne vous donnera peut-être pas toujours les données les *plus récentes*, mais il vous donnera toujours *une* réponse. 3. **Tolérance aux Partitions (P) :** Il s'agit de la manière dont le système gère les pannes réseau. Dans un système distribué, différentes parties (nœuds) communiquent via un réseau. Une partition réseau se produit lorsque la connexion réseau entre certains de ces nœuds est rompue, divisant effectivement le système en groupes isolés qui ne peuvent pas se parler. Un système tolérant aux partitions continue de fonctionner et de fonctionner même lorsque ces pannes réseau se produisent. Dans les systèmes distribués modernes, les partitions réseau sont une réalité inévitable, vous avez donc pratiquement *toujours* besoin de la Tolérance aux Partitions. ### Pourquoi vous ne pouvez garantir que deux des trois Le cœur du théorème CAP réside dans ce qui se passe lorsqu'une partition réseau se produit. Étant donné que les pannes réseau sont inévitables dans tout système véritablement distribué (ce qui signifie que vous *devez* avoir la Tolérance aux Partitions), le véritable choix auquel vous êtes confronté est entre la Cohérence et la Disponibilité pendant un tel événement. Supposons que notre magasin de données soit divisé en deux groupes de serveurs qui ne peuvent pas communiquer. Maintenant, un utilisateur essaie d'écrire de nouvelles données sur un serveur du groupe A, et un autre utilisateur essaie de lire ces mêmes données à partir d'un serveur du groupe B. * **Si vous privilégiez la Cohérence (système CP) :** Pour garantir que l'utilisateur du groupe B ne lise pas de données obsolètes, le système peut décider que les serveurs du groupe B ne peuvent pas répondre aux requêtes de lecture pour ces données tant qu'ils ne peuvent pas communiquer à nouveau avec le groupe A et confirmer qu'ils ont la dernière version. Cela signifie que le groupe B devient *indisponible* pour ces données spécifiques jusqu'à ce que la partition soit rétablie. Vous maintenez la cohérence, mais vous sacrifiez la disponibilité. * **Si vous privilégiez la Disponibilité (système AP) :** Pour garantir que l'utilisateur du groupe B reçoive toujours une réponse, le serveur du groupe B peut servir les données qu'il possède, même s'il sait qu'il n'a pas pu synchroniser avec le groupe A. Cela signifie que l'utilisateur du groupe B peut obtenir des données légèrement obsolètes par rapport à ce que l'utilisateur du groupe A vient d'écrire. Vous maintenez la disponibilité, mais vous sacrifiez la cohérence immédiate (vous obtenez une "cohérence éventuelle", ce qui signifie qu'elle deviendra cohérente une fois la partition rétablie). ### Une analogie facile à comprendre : la banque avec deux distributeurs automatiques Imaginez une banque avec deux distributeurs automatiques, ATM A et ATM B, tous deux connectés à votre unique compte bancaire. Le système bancaire central est ce qui suit votre solde réel. * **Cohérence :** Si vous retirez 100 $ du distributeur A, et que vous consultez immédiatement votre solde au distributeur B, il affiche instantanément 100 $ de moins. * **Disponibilité :** Les deux distributeurs automatiques fonctionnent toujours et vous permettent d'effectuer des transactions. * **Tolérance aux Partitions :** Si le câble réseau reliant le distributeur A à la banque centrale (ou au distributeur B) est coupé, le distributeur A peut toujours fonctionner indépendamment. Voyons maintenant le compromis lorsque ce câble réseau vers le distributeur A est coupé (une partition) : * **Priorité à la Cohérence (CP) :** Si vous essayez de retirer de l'argent du distributeur A, il peut afficher un message "Hors service" ou "Transaction indisponible". Pourquoi ? Parce qu'il ne peut pas communiquer avec la banque centrale pour vérifier votre solde actuel et s'assurer qu'il ne vous permet pas de dépasser votre solde. Il sacrifie la disponibilité pour garantir que toute transaction qu'il *effectue* est absolument cohérente avec l'enregistrement central. * **Priorité à la Disponibilité (AP) :** Si vous essayez de retirer de l'argent du distributeur A, il peut vous le permettre en fonction de son dernier solde connu, même s'il ne peut pas le confirmer avec la banque centrale. Il est disponible, mais il y a un risque : vous pourriez dépasser votre solde, ou l'enregistrement de la banque centrale pourrait temporairement différer de ce que le distributeur A pense. Une fois la connexion réseau rétablie, le système réconciliera les soldes, mais pendant un certain temps, ils étaient incohérents. ### Exemples concrets de compromis CAP 1. **Exemple de système CP : Bases de données relationnelles traditionnelles (par exemple, PostgreSQL, MySQL) avec des paramètres de cohérence forts, ou systèmes de transactions financières.** * **Choix :** Ces systèmes privilégient la Cohérence et la Tolérance aux Partitions. Lorsqu'une partition réseau se produit, ils rendront souvent des parties du système indisponibles pour garantir que toutes les données restent parfaitement cohérentes. Si un serveur ne peut pas confirmer qu'il a les dernières données, il ne les servira pas. * **Impact sur les utilisateurs finaux :** Les utilisateurs peuvent rencontrer des retards occasionnels ou des messages temporaires "système indisponible" lors de problèmes réseau ou de pannes de serveur. Par exemple, si vous essayez d'effectuer un virement bancaire et que le système connaît une partition, votre transaction peut être retenue ou échouer, mais vous avez la garantie que le solde de votre compte sera toujours exact et ne présentera jamais de valeurs contradictoires. Ceci est crucial pour les applications où l'intégrité des données est primordiale. 2. **Exemple de système AP : Flux de réseaux sociaux (par exemple, Facebook, Twitter) ou paniers d'achat de commerce électronique (par exemple, Amazon DynamoDB souvent configuré pour la cohérence éventuelle).** * **Choix :** Ces systèmes privilégient la Disponibilité et la Tolérance aux Partitions. Lorsqu'une partition réseau se produit, ils continuent de servir les requêtes, même si cela signifie que certains utilisateurs peuvent voir temporairement des informations légèrement obsolètes. Ils visent la "cohérence éventuelle", ce qui signifie que les données deviendront cohérentes avec le temps une fois la partition résolue. * **Impact sur les utilisateurs finaux :** Les utilisateurs obtiennent presque toujours une réponse. Par exemple, si vous publiez une mise à jour sur les réseaux sociaux, il peut falloir quelques secondes, voire quelques minutes, pour que *tous* vos abonnés la voient, surtout s'il y a un problème réseau. De même, si vous ajoutez un article à votre panier Amazon, il peut brièvement apparaître comme disponible même s'il vient d'être vendu, ou votre panier peut ne pas refléter immédiatement un article ajouté depuis un autre appareil. Le système privilégie le maintien du service et de la réactivité, acceptant que les incohérences temporaires soient acceptables pour une meilleure expérience utilisateur. ### Questions pour les prochaines réunions d'architecture Sur la base de cette compréhension, voici quelques questions essentielles que vous devriez poser lors de nos réunions d'architecture : * **Pour quels types de données ou opérations spécifiques la cohérence forte est-elle absolument essentielle pour notre entreprise ?** (par exemple, transactions financières, décomptes d'inventaire, authentification utilisateur). Où ne pouvons-nous *pas* tolérer d'incohérence ? * **Pour quels types de données ou opérations pouvons-nous tolérer la cohérence éventuelle ou la fraîcheur temporaire des données ?** (par exemple, mises à jour de profil utilisateur, moteurs de recommandation, données analytiques). Où la disponibilité est-elle plus importante que la cohérence immédiate ? * **Quelles sont les implications commerciales d'une indisponibilité temporaire par rapport à une incohérence temporaire pour nos flux d'utilisateurs principaux ?** Comment chaque choix affecte-t-il l'expérience utilisateur, les revenus et la confiance ? * **Si nous privilégions la disponibilité et la cohérence éventuelle, quelles sont nos stratégies pour gérer et résoudre les conflits de données lorsqu'ils surviennent inévitablement ?** Comment garantirons-nous que les données convergent correctement à terme ? * **Quels sont les temps de récupération et les stratégies attendus pour différents types de partitions réseau ?** Dans quel délai pouvons-nous rétablir la cohérence complète après un événement ? * **Comment allons-nous surveiller la cohérence et la disponibilité de notre magasin de données distribué ?** Quelles métriques allons-nous suivre pour nous assurer que nous répondons à nos exigences commerciales ? Comprendre le théorème CAP ne consiste pas à choisir une "meilleure" option, mais à faire des compromis éclairés qui correspondent aux besoins de notre entreprise et aux attentes de nos utilisateurs. Votre contribution sur ces compromis sera inestimable.

Si vous participez à des discussions d'architecture sur le passage d'une base de données à un système distribué, le théorème CAP est l'un des modèles mentaux les plus utiles à avoir. En bref : lorsqu'un système distribué est divisé par un problème réseau, vous devez généralement choisir entre maintenir les données parfaitement synchronisées partout immédiatement, ou maintenir le système entièrement réactif. Vous n'obtenez pas les deux garanties en même temps. Voici une façon pratique d'y penser. Un magasin de données distribué signifie que vos données ne se trouvent plus exactement à un seul endroit. Elles peuvent être répliquées sur plusieurs machines, centres de données ou régions cloud. Cela vous offre évolutivité et résilience, mais introduit également une nouvelle réalité : parfois, ces machines ne peuvent pas communiquer de manière fiable entre elles. Les réseaux ne sont pas parfaits. Les messages peuvent être retardés, perdus ou bloqués. CAP concerne ce que fait votre système dans ces moments-là. La cohérence, en termes pratiques, signifie que chaque utilisateur voit la même réponse à jour pour un élément de données, quelle que soit la réplique ou le nœud qu'il contacte. Si un client modifie son adresse de livraison, puis actualise immédiatement la page ou ouvre l'application sur un autre appareil, la cohérence signifie qu'il voit la nouvelle adresse partout immédiatement. Il n'y a pas de période où un serveur indique que l'adresse est ancienne et un autre qu'elle est nouvelle. Pour les décisions produit, la cohérence concerne la capacité de l'entreprise à tolérer que des personnes voient des informations obsolètes ou contradictoires. La disponibilité, en termes pratiques, signifie que le système continue de répondre aux requêtes avec succès même lorsque certaines de ses parties rencontrent des problèmes. L'utilisateur obtient une réponse, pas un délai d'attente ou une erreur. Par exemple, si un acheteur ajoute un article au panier, un système disponible acceptera l'action et renverra quelque chose d'utilisable, même si une région ou une réplique est inaccessible. Pour les équipes produit, la disponibilité concerne la nécessité pour l'expérience utilisateur de continuer à avancer à tout prix, même si les données renvoyées ne sont pas les plus récentes. La tolérance aux partitions, en termes pratiques, signifie que le système continue de fonctionner malgré les pannes réseau entre les parties du système. Une partition n'est pas nécessairement une panne spectaculaire ; il peut s'agir de toute rupture de communication où un groupe de serveurs ne peut pas coordonner de manière fiable avec un autre groupe. Dans un système distribué, vous ne pouvez pas vraiment vous soustraire à ce problème. Si vous avez des machines dans différentes zones ou régions, les partitions sont une réalité. La tolérance aux partitions est donc moins une fonctionnalité que vous choisissez qu'une condition pour laquelle vous devez concevoir. C'est pourquoi on dit souvent que CAP concerne le compromis entre la cohérence et la disponibilité lorsqu'une partition se produit. En fonctionnement normal, de nombreux systèmes peuvent fournir les deux. Le choix douloureux apparaît lorsque le réseau est peu fiable et que les répliques ne peuvent pas coordonner en toute sécurité. Pourquoi ne peut-on pas garantir les trois à la fois ? Imaginez deux répliques de votre base de données, une à New York et une à Dublin. Un problème réseau les empêche soudainement de communiquer entre elles. Maintenant, un client met à jour son compte à New York, tandis qu'une autre requête lit ce compte depuis Dublin. Si vous privilégiez la cohérence, le côté de Dublin doit éviter de répondre avec des données potentiellement obsolètes. Il peut devoir retarder, rejeter ou générer une erreur pour cette lecture jusqu'à ce qu'il puisse confirmer l'état le plus récent. Cela préserve une réponse unique et correcte, mais réduit la disponibilité car certaines requêtes n'aboutissent pas. Si vous privilégiez la disponibilité, Dublin doit continuer à répondre même s'il ne peut pas confirmer avec New York. Il peut renvoyer d'anciennes données ou accepter des écritures qui nécessiteront une réconciliation ultérieure. Cela maintient le produit réactif, mais la cohérence est temporairement affaiblie car différents utilisateurs peuvent voir différentes vérités. La force derrière le compromis est simple : lorsque les serveurs ne peuvent pas communiquer, ils ne peuvent pas savoir avec certitude qu'ils prennent des décisions globalement correctes en temps réel. Soit vous attendez la coordination et risquez une interruption, soit vous continuez à servir les requêtes et risquez une divergence. Une analogie mémorable est une chaîne de cafés partageant un solde de carte cadeau. Supposons que le solde soit stocké dans deux succursales et que le lien Internet entre elles soit coupé. Si les deux succursales continuent d'accepter la même carte cadeau pendant la panne, le client pourrait dépenser l'argent deux fois. C'est une haute disponibilité, une cohérence plus faible. Si les succursales refusent d'utiliser la carte cadeau jusqu'à ce que la connexion soit rétablie, elles empêchent les dépenses excessives. C'est une cohérence plus élevée, une disponibilité plus faible. Et la raison pour laquelle cela importe est que les succursales sont partitionnées : elles ne peuvent pas communiquer. Cette analogie fonctionne bien car la question commerciale devient évidente : qu'est-ce qui est le pire pour nous et nos clients pendant une panne, refuser temporairement une transaction, ou autoriser temporairement un état contradictoire que nous nettoyons plus tard ? Maintenant, rendons cela concret avec des exemples concrets. Un exemple est les bases de données relationnelles traditionnelles déployées dans une configuration primaire-réplique avec une forte cohérence sur le primaire pour les écritures critiques. Pensez aux systèmes utilisés pour la banque, les paiements, la réservation d'inventaire ou le placement de commandes. Si le système ne peut pas confirmer en toute sécurité le solde ou le nombre de stocks actuel, il peut rejeter ou retarder la transaction plutôt que de risquer un double débit ou une survente. En termes CAP, lors d'une partition, ces systèmes penchent souvent vers la cohérence plutôt que vers la disponibilité pour les opérations critiques. Pour les utilisateurs finaux, cela signifie qu'ils peuvent voir des erreurs comme « veuillez réessayer plus tard » pendant les pannes, mais ils sont moins susceptibles de voir des états impossibles tels qu'un solde négatif ou deux personnes achetant le dernier siège. Un deuxième exemple est le DNS, le système qui mappe les noms de domaine aux adresses IP. Le DNS est fortement distribué et conçu pour rester réactif à l'échelle mondiale. Les changements se propagent au fil du temps, et différents utilisateurs peuvent obtenir temporairement des réponses différentes en fonction des caches et du timing. Cela signifie qu'il privilégie la disponibilité et la tolérance aux partitions par rapport à la cohérence immédiate. Pour les utilisateurs finaux, cela signifie généralement que les sites Web restent accessibles la plupart du temps, mais un changement DNS récent peut prendre du temps à apparaître partout. Un troisième exemple est les systèmes de type Amazon Dynamo et de nombreux magasins de paniers d'achat ou de sessions inspirés de cette conception. Ces systèmes sont conçus pour rester opérationnels même en cas de problèmes réseau, acceptant souvent les écritures dans plusieurs endroits et les réconciliant plus tard. Ils conviennent bien lorsque la perte d'une requête est pire que l'affichage temporaire de données légèrement obsolètes. Pour les utilisateurs finaux, cela peut signifier qu'une mise à jour du panier réussit immédiatement même en cas de problèmes d'infrastructure, mais dans des cas extrêmes, ils peuvent brièvement voir une ancienne version du panier ou rencontrer des articles dupliqués/contradictoires que le système résout plus tard. Un quatrième exemple concerne les systèmes comme Google Spanner ou les bases de données SQL distribuées qui investissent massivement dans la coordination pour fournir une cohérence forte sur les nœuds distribués. Ils peuvent offrir un modèle de programmation plus proche d'une base de données, mais lors de certaines pannes, ils peuvent choisir de bloquer ou d'échouer certaines opérations plutôt que de renvoyer des résultats incertains. Pour les utilisateurs finaux, cela signifie souvent une correction plus prévisible, mais potentiellement une latence plus élevée ou une disponibilité d'écriture réduite dans certains scénarios de panne. La leçon produit importante est qu'il n'y a pas de choix CAP universellement meilleur. La bonne réponse dépend de la promesse utilisateur que vous faites. Si vous créez un registre de paiements, la cohérence est souvent plus importante que d'accepter toujours les requêtes. Il est généralement préférable de dire à un utilisateur « nous ne pouvons pas traiter cela pour le moment » plutôt que de risquer de facturer deux fois. Si vous créez un fil d'actualité social, un service de recommandation, un tableau de bord analytique ou un panier d'achat, la disponibilité peut être plus importante. Les utilisateurs tolèrent souvent de voir des données légèrement anciennes pendant une courte période si l'application reste rapide et utilisable. De plus, le même produit peut choisir différents compromis pour différentes actions. Une plateforme de vente au détail peut exiger une cohérence forte pour la réservation d'inventaire et la capture de paiement, mais autoriser une cohérence éventuelle pour les vues de produits, les recommandations et les décomptes d'avis. CAP n'est pas une décision pour toute l'entreprise ; c'est souvent un ensemble de décisions par flux de travail. Cela nous amène à la partie la plus utile pour vos réunions : ce que vous devriez demander. Premièrement, demandez quelles actions utilisateur nécessitent absolument des données correctes et à jour, et lesquelles peuvent tolérer un délai ou une obsolescence. Autrement dit : où « faux mais réactif » est-il acceptable, et où ne l'est-il pas ? Deuxièmement, demandez ce qui se passe lors d'une partition réseau ou d'une panne régionale. Les écritures sont-elles rejetées, mises en file d'attente, ou acceptées localement et réconciliées plus tard ? Cela révèle le comportement opérationnel réel, pas seulement le diagramme. Troisièmement, demandez quelles incohérences les utilisateurs pourraient réellement voir. Pourraient-ils voir un ancien solde, des notifications en double, un article apparaître en stock alors qu'il ne l'est pas, ou une mise à jour de profil visible sur un écran mais pas sur un autre ? Les décisions produit dépendent de ces modes de défaillance concrets. Quatrièmement, demandez combien de temps l'incohérence peut durer. Secondes, minutes, heures ? « Éventuellement cohérent » est trop vague en soi. La fenêtre acceptable dépend de la fonctionnalité. Cinquièmement, demandez quels risques commerciaux importent le plus : pertes de ventes dues aux temps d'arrêt, charge de support due à des données confuses, risque juridique/de conformité dû à des enregistrements incorrects, ou perte financière due à un double traitement. Les compromis CAP doivent être liés à l'impact commercial. Sixièmement, demandez si différentes parties du système peuvent utiliser différents modèles de cohérence. Souvent, la réponse devrait être oui. Cela permet d'éviter de sur-ingénierer le tout selon la norme la plus stricte. Septièmement, demandez comment les conflits sont résolus si le système accepte les écritures pendant les partitions. Quelle est la règle si deux régions mettent à jour le même enregistrement différemment ? La dernière écriture gagne ? Fusion ? Examen manuel ? Des règles de résolution de conflits cachées peuvent créer de mauvaises expériences utilisateur. Huitièmement, demandez quelle sera l'expérience utilisateur de repli dans les scénarios de défaillance. Si le système privilégie la cohérence à la disponibilité, quel modèle d'erreur ou de nouvelle tentative les utilisateurs verront-ils ? S'il privilégie la disponibilité à la cohérence, comment communiquerons-nous l'incertitude temporaire ? Neuvièmement, demandez quelle observabilité existe. Comment saurons-nous quand le système est partitionné, quand les répliques sont en retard, et quand les utilisateurs voient des données obsolètes ? Les équipes produit et support ont besoin de visibilité à ce sujet. Dixièmement, demandez si les exigences réglementaires ou contractuelles imposent une cohérence plus forte pour certains types de données, tels que les paiements, l'identité, les pistes d'audit ou les enregistrements de consentement. Si vous voulez retenir une phrase pour la réunion, utilisez celle-ci : CAP ne consiste pas à choisir un mot à la mode préféré ; il s'agit de décider ce que le produit doit faire lorsque des parties du système ne peuvent pas se mettre d'accord parce que le réseau est peu fiable. Un bon chef de produit ne demande pas : « Sommes-nous CP ou AP ? » comme une étiquette abstraite. Une meilleure question est : « Pour chaque flux de travail utilisateur important, lorsque le système est sous contrainte, préférons-nous bloquer l'action ou risquer d'afficher/accepter des données obsolètes ou contradictoires, et pourquoi ? » C'est à ce niveau que CAP devient utile pour les décisions d'architecture. Il transforme un théorème théorique en une conversation sur les compromis produit concernant la correction, la disponibilité, la confiance des utilisateurs et le risque commercial.