Expliquer la cohérence éventuelle aux développeurs web juniors

Cohérence éventuelle, expliquée aux développeurs web juniors

Lorsque vous créez une application CRUD de base, vous avez généralement une seule base de données. Vous écrivez une valeur, vous la relisez, et vous obtenez exactement ce que vous venez d'écrire. Ce comportement immédiat et prévisible est appelé cohérence forte (ou immédiate). Cela semble évident, presque comme une loi de la nature. Mais une fois qu'une application devient suffisamment grande pour fonctionner sur de nombreux serveurs répartis dans le monde, cette simple garantie devient étonnamment coûteuse. La cohérence éventuelle est le compromis que de nombreux systèmes modernes acceptent en échange de vitesse et de fiabilité.

Ce que signifie réellement la cohérence éventuelle

Les grands systèmes ne conservent pas vos données en un seul endroit. Ils en conservent plusieurs copies (appelées réplicas) sur différents serveurs, souvent dans différentes villes ou pays. Ceci est fait pour que l'application reste rapide pour les utilisateurs partout et continue de fonctionner même si un serveur tombe en panne.

Le problème est que lorsque vous mettez à jour des données, toutes ces copies ne peuvent pas être mises à jour au même instant. Il y a toujours un petit délai pendant que le changement se propage d'une copie à l'autre. La cohérence éventuelle est une simple promesse concernant ce délai : si aucune nouvelle mise à jour n'est effectuée, alors après une courte période, toutes les copies seront d'accord sur la même valeur. En d'autres termes, le système deviendra cohérent éventuellement, pas instantanément. Pendant cette courte fenêtre, différents utilisateurs (ou même le même utilisateur lors de requêtes différentes) peuvent voir des versions légèrement différentes des données.

Pourquoi un système choisirait cela intentionnellement

Cela ressemble à un inconvénient, alors pourquoi le choisir ? La réponse honnête est que les systèmes distribués imposent un compromis. Lorsque les serveurs sont répartis et que les réseaux tombent en panne ou ralentissent occasionnellement, un système peut soit :

1. Attendre que chaque copie confirme la mise à jour avant de répondre. Cela vous donne une cohérence forte, mais cela ralentit les écritures, et si un serveur est inaccessible, toute l'opération peut être bloquée ou échouer.

2. Répondre rapidement après la mise à jour d'une copie, puis synchroniser les autres en arrière-plan. Cela vous donne de la vitesse et de la disponibilité - l'application reste rapide et continue d'accepter des requêtes même lorsque des parties du système sont en difficulté - au prix d'un désaccord temporaire entre les copies.

La cohérence éventuelle est l'option deux. Les systèmes qui servent des millions d'utilisateurs - réseaux sociaux, boutiques en ligne, plateformes de streaming - valorisent souvent d'être rapides et toujours disponibles plus qu'une synchronisation parfaite à chaque milliseconde. Un nombre de likes qui est erroné de un pendant deux secondes est généralement un prix raisonnable à payer pour un site qui ne semble jamais lent et qui tombe rarement en panne.

Un exemple concret d'e-commerce/médias sociaux

Imaginez un post sur les réseaux sociaux qui vient de devenir viral. Des milliers de personnes l'aiment au même moment. Le nombre de likes est stocké sur plusieurs réplicas. Vous aimez le post et voyez immédiatement le compteur passer de 1 000 à 1 001. Un ami dans un autre pays rafraîchit au même instant et voit toujours 1 000 pendant une seconde ou deux, car la mise à jour n'a pas encore atteint son réplica le plus proche. Aucun de vous ne voit un "bug" - le système est juste en train de rattraper son retard. Quelques secondes plus tard, vous voyez tous les deux le même nombre. La même idée s'applique à un avis sur un produit e-commerce : vous publiez un avis et le voyez instantanément (car votre appareil affiche votre propre action), mais un autre acheteur pourrait ne pas le voir pendant un moment jusqu'à ce qu'il se propage.

Une analogie simple

Pensez à un chat de groupe où plusieurs amis planifient un dîner, mais tout le monde communique par l'intermédiaire de différents membres du groupe qui relaient les messages. Quand quelqu'un dit "retrouvons-nous à 19h", ce message prend un peu de temps pour atteindre tout le monde. Pendant quelques secondes, certains amis pensent que le plan est 19h00 tandis que d'autres n'ont pas encore reçu la mise à jour. Personne ne ment, et le message n'est pas perdu - il n'est juste pas arrivé partout en même temps. Donnez-lui un moment, et tout le groupe est d'accord. Cette courte période "intermédiaire" est exactement ce que ressent la cohérence éventuelle.

Ce que cela signifie pour les utilisateurs et la conception de votre application

L'effet pratique est que vous ne pouvez plus supposer "ce que j'ai écrit est ce que tout le monde lit immédiatement". Les lectures obsolètes (voir des données légèrement anciennes) sont normales, pas des échecs. Le danger est que cela puisse confondre ou même nuire aux utilisateurs si vous l'ignorez - par exemple, si quelqu'un passe une commande, voit un historique de commandes vide et suppose que la commande a échoué, il pourrait commander à nouveau et être facturé deux fois. Une bonne conception consiste à éviter cette confusion.

Techniques de conception pour réduire la confusion et les dommages

1. Lire ses propres écritures (montrer immédiatement aux utilisateurs leurs propres actions). Même si le système global est encore en cours de synchronisation, assurez-vous qu'un utilisateur voit toujours le résultat de sa propre action immédiatement. Après que quelqu'un ait posté un commentaire ou ajouté un article au panier, mettez à jour de manière optimiste son propre écran afin qu'il reflète son changement instantanément. Cela évite la pire expérience : un utilisateur fait quelque chose et ne voit aucun effet.

2. Communiquer l'état honnêtement dans l'interface utilisateur. Ne prétendez pas que tout est définitif quand ce ne l'est pas. Utilisez des signaux clairs et temporaires comme "Envoi...", "En attente", "Sauvegarde", ou un spinner subtil, puis confirmez une fois que le changement est reconnu. Si quelque chose est encore en cours de propagation, une petite note comme "Cela peut prendre un moment pour apparaître aux autres" établit la bonne attente et empêche les actions dupliquées par panique.

3. Rendre les opérations répétables (idempotentes) et éviter les doubles préjudices. Concevez des actions importantes de manière à ce que les répéter deux fois ne cause pas de dommages. Par exemple, donnez à chaque commande ou paiement un identifiant de requête unique afin que si un utilisateur réessaie parce qu'il n'a pas vu de confirmation, le système reconnaisse qu'il s'agit de la même action et ne le facture pas deux fois. Cela protège les utilisateurs précisément pendant la fenêtre d'incohérence lorsqu'ils sont les plus susceptibles de réessayer.

4. Choisir une cohérence plus forte uniquement là où elle compte vraiment. La cohérence éventuelle convient pour les compteurs de likes, les compteurs de vues ou les listes de recommandations. Elle ne convient pas pour la dernière étape d'un paiement ou pour vérifier si le dernier article en stock est toujours disponible. Utilisez des garanties plus fortes pour le petit ensemble d'opérations où une erreur est coûteuse, et acceptez la cohérence éventuelle pour tout le reste. Savoir quelles données nécessitent quelle garantie est l'une des décisions les plus précieuses que vous puissiez prendre.

Le compromis fondamental, sans simplification excessive

La cohérence éventuelle n'est pas "plus faible" dans un sens négligent - c'est un choix délibéré qui offre vitesse et disponibilité au prix d'un désaccord temporaire entre les copies de vos données. Vous ne pouvez pas avoir une cohérence instantanée parfaite, une disponibilité parfaite et une tolérance parfaite aux pannes réseau en même temps dans un système distribué ; quelque chose doit céder. La cohérence éventuelle sacrifie l'accord instantané. Votre travail en tant que développeur n'est pas de lutter contre cette réalité, mais de la concevoir : montrer immédiatement aux utilisateurs leurs propres changements, communiquer clairement les états en attente, rendre les actions risquées sûres à réessayer, et réserver la cohérence forte aux quelques endroits où la correction ne peut pas attendre. Faites cela, et l'incohérence temporaire deviendra un détail d'implémentation invisible au lieu d'une source de confusion pour l'utilisateur.

À mesure que les applications web se développent, en particulier celles qui servent de nombreux utilisateurs ou fonctionnent à l’échelle mondiale, les développeurs rencontrent souvent un concept appelé cohérence éventuelle. Il s’agit d’un compromis fondamental dans les systèmes distribués modernes qui permet une plus grande évolutivité et disponibilité, mais qui exige une manière différente de penser les données.

Qu’est-ce que la cohérence éventuelle ?

Dans une application web typique que vous avez peut-être développée, lorsque vous mettez à jour des données dans une base de données (par exemple, modifier le profil d’un utilisateur), vous vous attendez à ce que toute lecture ultérieure reflète immédiatement ce changement. C’est ce qu’on appelle la cohérence immédiate. Toutes les copies des données sont mises à jour et synchronisées avant que l’opération d’écriture ne soit considérée comme terminée.

La cohérence éventuelle, en revanche, signifie qu’après une opération d’écriture réussie, les données peuvent ne pas être immédiatement cohérentes sur toutes les copies du système. À la place, le système garantit que si aucune nouvelle mise à jour n’est effectuée sur un élément de données donné, alors, à terme, tous les accès à cet élément renverront la dernière valeur mise à jour. Il y a un délai, mais les données deviendront cohérentes avec le temps.

Pourquoi choisir la cohérence éventuelle ?

Les systèmes web modernes, comme les grandes plateformes de réseaux sociaux ou les sites de commerce électronique, doivent souvent gérer des millions d’utilisateurs et des quantités massives de données. Pour y parvenir, ils ne peuvent pas s’appuyer sur une seule base de données ; ils répartissent les données sur de nombreux serveurs, souvent dans différentes zones géographiques. Maintenir toutes ces copies distribuées en cohérence immédiate est extrêmement difficile et coûteux. Cela voudrait dire que chaque opération d’écriture devrait attendre que toutes les copies accusent réception de la mise à jour, ce qui serait lent et sujet aux échecs si ne serait-ce qu’un seul serveur était temporairement indisponible.

La cohérence éventuelle permet aux systèmes de privilégier la disponibilité (le système reste opérationnel même si certaines parties tombent en panne) et les performances (les écritures et les lectures sont rapides) plutôt que la cohérence immédiate. En permettant aux écritures de se terminer rapidement sur un sous-ensemble de serveurs, puis en propageant ensuite ces changements de manière asynchrone aux autres, le système peut gérer davantage de trafic et rester réactif.

Effets pratiques sur les utilisateurs et la conception des applications

Pour les utilisateurs, l’effet le plus visible est qu’ils peuvent occasionnellement voir des informations légèrement obsolètes pendant une courte période. Pour les concepteurs d’applications, cela signifie que vous ne pouvez pas toujours supposer qu’une opération de lecture renverra les données absolument les plus récentes, surtout peu de temps après une écriture.

Exemple concret (réseaux sociaux) :
Imaginez une application de réseau social où les utilisateurs peuvent « aimer » une publication. Lorsque l’utilisateur A aime une publication, son client affiche immédiatement le compteur de « j’aime » incrémenté. Cependant, en raison de la cohérence éventuelle, l’utilisateur B, qui est connecté à un autre serveur, peut voir l’ancien compteur de « j’aime » pendant quelques secondes, voire une minute, jusqu’à ce que la mise à jour soit propagée à son serveur. À terme, les deux utilisateurs verront le même compteur de « j’aime », correct.

Analogie simple :
Pensez à une grande entreprise avec de nombreuses agences. Lorsqu’une personne met à jour ses coordonnées à l’agence A, ces informations sont immédiatement disponibles à l’agence A. Cependant, il peut falloir un certain temps (par exemple, une synchronisation nocturne ou un transfert de données horaire) pour que ces informations mises à jour atteignent toutes les autres agences. Pendant une courte période, si quelqu’un à l’agence B consulte les coordonnées de cette personne, il peut voir les anciennes informations. Mais à terme, toutes les agences disposeront des informations correctes et mises à jour.

Techniques de conception pour atténuer l’incohérence

Bien que la cohérence éventuelle soit un outil puissant, elle exige une conception d’application soignée afin d’éviter la confusion des utilisateurs ou les problèmes d’intégrité des données. Voici trois techniques :

1. Mises à jour optimistes de l’interface et Read-Your-Writes : Lorsqu’un utilisateur effectue une action (comme publier un commentaire ou aimer un élément), mettez immédiatement à jour son interface utilisateur pour refléter ce changement, même avant que le backend ne l’ait entièrement propagé. Cela donne à l’utilisateur un retour instantané. De plus, implémentez une cohérence de type « read-your-writes », qui garantit que l’utilisateur qui vient juste d’effectuer une écriture verra toujours ses propres changements les plus récents, même si d’autres utilisateurs peuvent temporairement voir des données plus anciennes. Cela peut être réalisé en dirigeant ses lectures suivantes vers le serveur sur lequel il vient d’écrire, ou en mettant en cache localement ses écritures récentes.

2. Interface informative et indicateurs d’état : Pour les données à cohérence éventuelle, envisagez d’ajouter des éléments d’interface qui informent l’utilisateur sur la fraîcheur des données. Il peut s’agir d’un horodatage du type « Dernière mise à jour il y a X minutes », d’un indicateur de chargement signalant que les données sont en cours d’actualisation, ou d’un message discret comme « Les changements peuvent mettre un moment à apparaître pour tout le monde. » Cela permet de gérer les attentes des utilisateurs et de réduire la confusion lorsqu’ils ne voient pas immédiatement une mise à jour attendue.

3. Utilisation stratégique et cohérence plus forte pour les chemins critiques : Toutes les données ne peuvent pas tolérer la cohérence éventuelle. Pour les opérations hautement critiques, telles que les transactions financières (par exemple, débiter de l’argent d’un compte) ou la gestion des stocks (par exemple, s’assurer qu’un article n’est vendu qu’une seule fois), vous devez utiliser des systèmes ou des modèles qui imposent une cohérence immédiate. Identifiez les parties de votre application où une incohérence temporaire est acceptable (par exemple, les fils d’actualité des réseaux sociaux, les profils utilisateurs, les compteurs de commentaires) et appliquez-y la cohérence éventuelle, tout en réservant des modèles de cohérence plus forts aux chemins de données véritablement critiques.