Comprenez pourquoi les bases de données distribuées assouplissent souvent la cohérence pour rester disponibles en cas de panne, comment fonctionnent CAP et les quorums, et quand choisir chaque approche.
Quand une base de données est répartie sur plusieurs machines (répliques), vous gagnez en vitesse et en résilience — mais vous introduisez aussi des périodes où ces machines ne sont pas parfaitement d'accord ou ne peuvent pas communiquer de façon fiable.
Cohérence signifie : après une écriture réussie, tout le monde lit la même valeur. Si vous mettez à jour l'email de votre profil, la lecture suivante — quel que soit la réplique — renvoie le nouvel email.
En pratique, les systèmes qui privilégient la cohérence peuvent retarder ou rejeter certaines requêtes durant des pannes pour éviter de renvoyer des réponses contradictoires.
Disponibilité signifie : le système répond à chaque requête, même si des serveurs sont hors service ou déconnectés. Vous n'obtenez peut-être pas la donnée la plus récente, mais vous obtenez une réponse.
En pratique, les systèmes qui privilégient la disponibilité peuvent accepter des écritures et servir des lectures alors même que des répliques sont en désaccord, puis réconcilier les différences plus tard.
Un compromis signifie que vous ne pouvez pas maximiser les deux objectifs en même temps dans tous les scénarios de panne. Si les répliques ne peuvent pas se coordonner, la base de données doit soit :
L'équilibre dépend des erreurs que vous pouvez tolérer : une courte indisponibilité ou une courte période de données erronées/anciennes. La plupart des systèmes réels se placent entre les deux — et rendent le compromis explicite.
Une base de données est « distribuée » quand elle stocke et sert des données depuis plusieurs machines (nœuds) qui se coordonnent via un réseau. Pour une application, elle peut toujours ressembler à une seule base de données — mais en coulisses, les requêtes peuvent être traitées par différents nœuds en différents lieux.
La plupart des bases distribuées répliquent les données : le même enregistrement est stocké sur plusieurs nœuds. Les raisons :
La réplication est puissante, mais elle pose immédiatement la question : si deux nœuds ont une copie de la même donnée, comment garantir qu'ils sont toujours d'accord ?
Sur un seul serveur, « en panne » est souvent évident : la machine est up ou non. Dans un système distribué, la panne est souvent partielle. Un nœud peut être vivant mais lent. Un lien réseau peut perdre des paquets. Une baie entière peut perdre la connectivité alors que le reste du cluster continue de tourner.
Ceci importe parce que les nœuds ne peuvent pas savoir instantanément si un autre nœud est vraiment tombé, temporairement injoignable, ou simplement retardé. Pendant qu'ils attendent de le découvrir, ils doivent décider quoi faire des lectures et écritures entrantes.
Avec un seul serveur, il y a une source de vérité : chaque lecture voit la dernière écriture réussie.
Avec plusieurs nœuds, « le plus récent » dépend de la coordination. Si une écriture réussit sur le nœud A mais que le nœud B est injoignable, la base de données doit :
Cette tension — rendue réelle par des réseaux imparfaits — est la raison pour laquelle la distribution change les règles.
Une partition réseau est une rupture de communication entre des nœuds qui sont censés fonctionner comme une seule base. Les nœuds peuvent être exécutés et sains, mais ils ne peuvent pas échanger de messages de façon fiable — à cause d'un commutateur défaillant, d'un lien surchargé, d'un mauvais routage, d'une règle de pare-feu mal configurée, ou même d'un « voisin bruyant » dans un réseau cloud.
Quand un système est réparti sur plusieurs machines (souvent sur des racks, zones ou régions), vous ne contrôlez plus chaque saut entre elles. Les réseaux perdent des paquets, introduisent des latences et parfois se divisent en « îlots ». À petite échelle ces événements sont rares ; à grande échelle ils deviennent routiniers. Même une courte perturbation suffit, parce que les bases de données ont besoin d'une coordination constante pour s'accorder sur ce qui s'est passé.
Pendant une partition, les deux côtés continuent de recevoir des requêtes. Si les utilisateurs peuvent écrire des deux côtés, chaque côté peut accepter des mises à jour que l'autre côté ne voit pas.
Exemple : le nœud A met à jour l'adresse d'un utilisateur en « Rue Nouvelle ». En même temps, le nœud B la met à jour en « Ancienne Rue Apt 2 ». Chaque côté croit que son écriture est la plus récente — car il ne peut pas comparer en temps réel.
Les partitions n'apparaissent pas sous forme de messages d'erreur clairs ; elles se manifestent par des comportements déroutants :
C'est le point de pression qui force un choix : quand le réseau ne garantit pas la communication, une base distribuée doit décider si elle privilégie la cohérence ou la disponibilité.
CAP est une façon concise de décrire ce qui arrive quand une base de données est répartie sur plusieurs machines.
Quand il n'y a pas de partition, beaucoup de systèmes peuvent apparaître cohérents et disponibles.
Quand il y a une partition, vous devez choisir quoi prioriser :
balance = 100 sur le serveur A.balance = 80.CAP ne veut pas dire « choisissez deux pour toujours ». Cela signifie que lors d'une partition, vous ne pouvez pas garantir simultanément Cohérence et Disponibilité. Hors partitions, on peut souvent se rapprocher des deux — jusqu'à ce que le réseau fasse des siennes.
Choisir la cohérence signifie que la base priorise « tout le monde voit la même vérité » plutôt que « toujours répondre ». En pratique, cela renvoie souvent à une cohérence forte, décrite comme linéarizable : une fois qu'une écriture est reconnue, toute lecture ultérieure (depuis n'importe où) renvoie cette valeur, comme s'il n'y avait qu'une seule copie à jour.
Quand le réseau se scinde et que les répliques ne peuvent plus se parler, un système fortement cohérent ne peut pas accepter en toute sécurité des mises à jour indépendantes de chaque côté. Pour protéger la justesse, il :
Pour l'utilisateur, cela peut ressembler à une panne même si certaines machines tournent encore.
Le principal bénéfice est une logique simplifiée. Le code applicatif peut se comporter comme s'il parlait à une seule base, pas à plusieurs répliques susceptibles de diverger. Cela réduit les « moments étranges » comme :
Vous obtenez aussi des modèles mentaux plus propres pour l'audit, la facturation et tout ce qui doit être correct du premier coup.
La cohérence a un coût réel :
Si votre produit ne tolère pas des requêtes échouées pendant des pannes partielles, la cohérence forte peut sembler coûteuse — même si c'est le bon choix pour la correction.
Choisir la disponibilité signifie optimiser pour une promesse simple : le système répond, même quand des parties de l'infrastructure sont dégradées. En pratique, « haute disponibilité » n'est pas « pas d'erreurs du tout » — c'est que la plupart des requêtes obtiennent toujours une réponse pendant des pannes de nœuds, des répliques surchargées ou des liens brisés.
Quand le réseau se scinde, les répliques ne peuvent plus se parler de façon fiable. Une base orientée disponibilité garde généralement le trafic côté accessible :
Cela maintient les applications en marche, mais signifie aussi que différentes répliques peuvent temporairement accepter des vérités différentes.
Vous obtenez une meilleure disponibilité : les utilisateurs peuvent continuer à naviguer, ajouter des articles au panier, poster des commentaires ou enregistrer des événements même si une région est isolée.
Vous obtenez aussi une expérience utilisateur plus fluide sous charge. Plutôt que des timeouts, votre app peut continuer (« votre mise à jour est enregistrée ») et synchroniser ensuite. Pour beaucoup de charges grand public et d'analytique, ce compromis en vaut la peine.
Le prix est que la base peut renvoyer des lectures obsolètes. Un utilisateur peut mettre à jour un profil sur une réplique, puis lire immédiatement depuis une autre et ne pas voir sa modification.
Vous risquez aussi des conflits d'écriture. Deux utilisateurs (ou le même utilisateur depuis deux lieux) peuvent modifier le même enregistrement sur différents côtés d'une partition. Quand la partition guérit, il faut réconcilier les historiques divergents. Selon les règles, une écriture peut l'emporter, des champs peuvent être fusionnés, ou la résolution peut nécessiter de la logique applicative.
Le design orienté disponibilité accepte le désaccord temporaire pour que le produit continue de répondre — puis investit dans la détection et la réparation des divergences.
Les quorums sont une technique de « vote » pratique que beaucoup de bases répliquées utilisent pour équilibrer cohérence et disponibilité. Plutôt que de faire confiance à une seule réplique, le système demande à suffisamment de répliques de se mettre d'accord.
On voit souvent les quorums décrits par trois nombres :
Une règle d'or est : si R + W > N, alors toute lecture recoupe au moins une réplique ayant la dernière écriture réussie, ce qui réduit les lectures obsolètes.
Si vous avez N=3 répliques :
Certains systèmes poussent W=3 (toutes les répliques) pour plus de cohérence, mais cela peut causer plus d'échecs d'écriture quand une réplique est lente ou hors ligne.
Les quorums n'éliminent pas les problèmes de partition — ils définissent qui est autorisé à progresser. Si le réseau se scinde en 2–1, le côté à 2 répliques peut toujours satisfaire R=2 et W=2, tandis que la réplique isolée ne le peut pas. Cela réduit les mises à jour conflictuelles, mais signifie que certains clients verront des erreurs ou des timeouts.
Les quorums apportent généralement plus de latence (plus de nœuds à contacter), plus de coût (trafic inter-nœuds) et un comportement de panne plus nuancé (les timeouts peuvent ressembler à de l'indisponibilité). L'avantage est un compromis réglable : vous pouvez ajuster R et W vers des lectures plus fraîches ou une réussite d'écriture plus élevée selon vos priorités.
La cohérence éventuelle autorise que les répliques soient temporairement hors synchronisation, tant qu'elles convergent vers la même valeur ensuite.
Imaginez une chaîne de cafés mettant à jour un panneau partagé « épuisé » pour une pâtisserie. Un magasin le marque « épuisé », mais la mise à jour n'atteint les autres que quelques minutes plus tard. Pendant cette fenêtre, un autre magasin peut encore afficher « disponible » et vendre le dernier exemplaire. Le système n'est pas « cassé » — les mises à jour rattrapent juste leur retard.
Quand les données se propagent, les clients peuvent voir des comportements surprenants :
Les systèmes éventuels ajoutent souvent des mécanismes en arrière-plan pour réduire les fenêtres d'incohérence :
C'est adapté quand la disponibilité prime sur l'actualité parfaite : flux d'activité, compteurs de vue, recommandations, profils mis en cache, logs/télémétrie et autres données non critiques où « correct dans un instant » suffit.
Quand une base accepte des écritures sur plusieurs répliques, elle peut finir avec des conflits : deux (ou plus) mises à jour du même élément faites indépendamment sur différentes répliques avant synchronisation.
Un exemple classique : un utilisateur met à jour son adresse d'expédition sur un appareil pendant qu'il change son numéro de téléphone sur un autre. Si chaque mise à jour arrive sur une réplique différente durant une coupure, le système doit décider du « vrai » enregistrement quand les répliques échangent leurs données.
Beaucoup de systèmes commencent par last-write-wins : l'écriture avec l'horodatage le plus récent écrase les autres.
C'est attrayant car facile à implémenter et rapide à calculer. Le revers est qu'il peut perdre silencieusement des données. Si le « plus récent » gagne, une modification plus ancienne mais importante peut être écrasée — même si les deux modifications touchaient des champs différents.
Cela suppose aussi que les horloges sont fiables. Le décalage d'horloge entre machines (ou clients) peut faire « gagner » la mauvaise mise à jour.
Une gestion des conflits plus sûre nécessite souvent de suivre l'historique causale.
Conceptuellement, les vecteurs de version (et variantes) attachent un petit métadonnée à chaque enregistrement résumant « quelle réplique a vu quelles mises à jour ». Quand les répliques échangent les versions, la base peut détecter si une version inclut l'autre (pas de conflit) ou si elles ont divergé (conflit à résoudre).
Certains systèmes utilisent des horloges logiques (ex. horloges de Lamport) ou des horloges logiques hybrides pour réduire la dépendance à l'heure murale tout en fournissant un indice d'ordre.
Une fois le conflit détecté, vous avez des choix :
La meilleure approche dépend de ce que « correct » signifie pour vos données — parfois perdre une écriture est acceptable, parfois c'est une erreur critique.
Choisir une posture cohérence/disponibilité n'est pas un débat philosophique — c'est une décision produit. Commencez par vous demander : quel est le coût d'être erroné un instant, et quel est le coût de dire « réessayez plus tard » ?
Certains domaines exigent une réponse unique et faisant autorité à l'écriture car « presque correct » reste incorrect :
Si l'impact d'une divergence temporaire est faible ou réversible, on peut pencher vers davantage de disponibilité.
Beaucoup d'expériences utilisateur acceptent des lectures légèrement anciennes :
Soyez explicite sur quelle ancienneté est acceptable : secondes, minutes ou heures. Ce budget de temps oriente vos choix de réplication et de quorum.
Quand les répliques ne s'accordent pas, vous avez typiquement trois issues UX :
Choisissez l'option la moins dommageable par fonctionnalité, pas globalement.
Penchez C (cohérence) si : des résultats erronés créent un risque financier/juridique, des problèmes de sécurité ou des actions irréversibles.
Penchez A (disponibilité) si : les utilisateurs valorisent la réactivité, les données obsolètes sont tolérables et les conflits peuvent être résolus ultérieurement.
En cas de doute, scindez le système : conservez des enregistrements critiques fortement cohérents et laissez les vues dérivées (feeds, caches, analytics) optimiser la disponibilité.
Vous n'êtes rarement obligé de choisir un unique « réglage de cohérence » pour tout le système. Beaucoup de bases modernes permettent de choisir la cohérence par opération — et les applications intelligentes en tirent parti pour fluidifier l'expérience sans nier le compromis.
Considérez la cohérence comme un réglage que vous tournez selon l'action de l'utilisateur :
Cela évite de payer le coût maximal de cohérence pour tout, tout en protégeant les opérations qui en ont vraiment besoin.
Un motif courant : fort pour les écritures, plus faible pour les lectures :
Parfois, on fait l'inverse : écritures rapides (mis en file / éventuelles) puis lectures fortes pour confirmer un résultat (« ma commande a-t-elle été passée ?").
Quand les réseaux tremblent, les clients réessaient. Rendez les réessais sûrs avec des clés d'idempotence pour que « soumettre une commande » exécuté deux fois ne crée pas deux commandes. Stockez et réutilisez le premier résultat quand la même clé est vue de nouveau.
Pour des actions multi-étapes entre services, utilisez une saga : chaque étape a une action compensatrice correspondante (rembourser, libérer une réservation, annuler un envoi). Cela rend le système récupérable même quand des parties divergent ou échouent temporairement.
Vous ne pouvez pas gérer le compromis cohérence/disponibilité si vous ne le voyez pas. Les incidents de production ressemblent souvent à des « pannes aléatoires » tant que vous n'avez pas les bonnes mesures et tests.
Commencez par un petit jeu de métriques qui se mappe directement à l'impact utilisateur :
Si possible, taguez les métriques par mode de cohérence (quorum vs local) et par région/zone pour repérer les divergences.
N'attendez pas la panne réelle. En staging, lancez des expériences de chaos qui simulent :
Vérifiez non seulement « le système reste up », mais quelles garanties tiennent : les lectures restent-elles fraîches, les écritures se bloquent-elles, les clients reçoivent-ils des erreurs claires ?
Ajoutez des alertes pour :
Enfin, formalisez les garanties : documentez ce que votre système promet en fonctionnement normal et pendant les partitions, et formez les équipes produit et support sur ce que les utilisateurs peuvent voir et comment réagir.
Si vous explorez ces compromis pour un nouveau produit, validez vite vos hypothèses — surtout sur les modes de panne, le comportement de retry et l'apparence du "obsolète" dans l'UI.
Une approche pratique : prototyper un petit parcours (chemin d'écriture, chemin de lecture, retry/idempotence et un job de réconciliation) avant de se lancer dans l'architecture complète. Avec des outils de prototypage, les équipes peuvent itérer rapidement sur modèles de données et API, et tester différents schémas de cohérence (par ex. écritures strictes + lectures relâchées) sans le coût d'un pipeline de développement traditionnel. Quand le prototype correspond au comportement désiré, exportez le code source et faites évoluer vers la production.
Dans une base de données répliquée, la même donnée existe sur plusieurs machines. Cela améliore la résilience et peut réduire la latence, mais crée des problèmes de coordination : les nœuds peuvent être lents, inaccessibles ou séparés par le réseau, donc ils ne peuvent pas toujours s'accorder instantanément sur la dernière écriture.
La cohérence signifie : après une écriture réussie, toute lecture ultérieure renvoie cette même valeur — quel que soit le nœud qui répond. En pratique, les systèmes font souvent respecter cela en retardant ou en rejetant certaines lectures/écritures jusqu'à ce qu'un nombre suffisant de répliques (ou le leader) confirme la mise à jour.
La disponibilité signifie que le système renvoie une réponse non-erreur à chaque requête, même si certains nœuds sont tombés ou ne peuvent pas communiquer. La réponse peut être obsolète, partielle ou basée sur l'état local, mais le système évite de bloquer les utilisateurs pendant les pannes.
Une partition réseau est une rupture de communication entre des nœuds qui devraient fonctionner comme un seul système. Les nœuds peuvent être en bonne santé, mais les messages ne traversent pas la coupure de manière fiable, ce qui force la base de données à choisir entre :
Pendant une partition, les deux côtés peuvent accepter des mises à jour qu'ils ne peuvent pas partager immédiatement. Cela peut conduire à :
Ce sont les effets visibles pour l'utilisateur lorsqu'il y a désaccord entre répliques.
Ce n'est pas « choisir deux sur trois » pour toujours. Cela signifie que lorsqu'une partition survient, vous ne pouvez pas garantir à la fois :
Hors partition, de nombreux systèmes semblent offrir les deux la plupart du temps — jusqu'à ce que le réseau se comporte mal.
Les quorums reposent sur un vote entre répliques :
Une règle courante est R + W > N pour réduire les lectures obsolètes. Les quorums ne suppriment pas les partitions ; ils définissent quel côté peut progresser (par ex. celui qui possède la majorité).
La cohérence éventuelle permet aux répliques d'être temporairement désynchronisées tant qu'elles convergent ensuite. Anomalies courantes :
Les systèmes atténuent souvent cela avec , et synchronisations périodiques d'.
Les conflits surviennent lorsque des répliques acceptent des écritures différentes sur le même élément durant une coupure. Stratégies de résolution :
Choisissez selon ce que signifie « correct » pour vos données.
Décidez selon le risque métier et le mode de défaillance que vos utilisateurs peuvent tolérer :
Patrons pratiques : niveaux de cohérence par opération, réessais sûrs avec idempotency keys, et sagas avec compensations pour les workflows multi-étapes.