Meerkat : comment Cloudflare veut résoudre le consensus distribué à l'échelle mondiale

Le 8 juillet 2026, l'équipe Research de Cloudflare a présenté Meerkat, un service de consensus distribué expérimental sur lequel elle travaille depuis un an. L'objectif : permettre à ses services internes de lire et modifier le même état de configuration depuis plus de 330 centres de données répartis dans le monde, sans jamais perdre en cohérence ni en disponibilité.

Le sujet paraît austère, mais il touche à un problème que tout ingénieur construisant un système distribué finit par rencontrer : comment faire en sorte que plusieurs machines, séparées par des milliers de kilomètres et des liaisons réseau imprévisibles, restent d'accord sur l'état du monde ? Cloudflare documente ici sa réponse, avec un choix technique qui rompt avec l'algorithme le plus utilisé du secteur : Raft.

Le consensus distribué, en bref

Pour ceux qui découvrent le sujet : un algorithme de consensus permet à un groupe de machines de se mettre d'accord sur une même séquence d'opérations (par exemple des écritures dans une base clé-valeur), tant qu'une majorité d'entre elles reste vivante et capable de communiquer. C'est la brique de base de toute base de données répliquée, de tout système de verrous distribués, ou de toute information du type "qui est le leader actuel". Chez Cloudflare, ce genre de donnée de plan de contrôle (control-plane data) sert par exemple à savoir où est stockée une instance de modèle IA, ou quelle machine a le droit d'écrire dans une base répliquée.

Pourquoi Raft ne suffit pas à l'échelle de Cloudflare

La majorité des systèmes de consensus déployés en production, à commencer par Raft, reposent sur l'élection d'un leader : une seule machine a le droit d'écrire à un instant donné. Si ce leader tombe (crash, dégradation réseau), le système entier devient indisponible en écriture le temps qu'un timeout expire et qu'une nouvelle élection ait lieu. Sur un réseau local aux latences stables, ce mécanisme fonctionne bien. Sur un réseau mondial aux latences imprévisibles comme celui de Cloudflare, régler correctement ces timeouts devient très difficile : trop courts, ils déclenchent des élections inutiles, trop longs, ils prolongent l'indisponibilité. Cloudflare indique avoir connu plusieurs incidents causés par des leaders indisponibles dans ses systèmes de consensus existants.

Meerkat et QuePaxa : le pari du "toujours disponible"

C'est ce constat qui a poussé l'équipe Research à construire Meerkat autour de QuePaxa, un algorithme de consensus publié en 2023 par des chercheurs de l'EPFL. Sa différence avec Raft : tous les replicas peuvent écrire à tout moment, et la progression du système n'est jamais interrompue par un timeout. Il n'y a donc pas de leader unique dont la chute suffit à bloquer les écritures. Selon Cloudflare, ce déploiement constituerait la première utilisation industrielle de QuePaxa à l'échelle mondiale. Deux applications sont d'ores et déjà construites au-dessus du journal de consensus de Meerkat : un magasin clé-valeur transactionnel et un système de leasing (baux et verrous distribués).

Ce que Meerkat garantit concrètement

Cloudflare fixe deux exigences précises à son système :

• La cohérence forte. Meerkat vise la linéarisabilité, le niveau de cohérence le plus strict : les opérations apparaissent s'exécuter dans le même ordre que dans la réalité, comme si tous les clients partageaient une seule mémoire. Le billet illustre la différence avec un exemple simple : une valeur x = 6 sur laquelle arrivent deux écritures concurrentes, x = x + 1 et x = x / 2. Selon le niveau de cohérence du système, un client peut lire des résultats différents après ces écritures ; en linéarisabilité, l'ordre reste cohérent avec le temps réel, ce qui évite au développeur de raisonner sur des cas tordus. La base clé-valeur de Meerkat va même plus loin en offrant de la sérialisabilité, un sujet que Cloudflare promet de détailler dans un prochain billet.
• La tolérance aux pannes. Le système doit rester disponible en lecture et en écriture, depuis n'importe quel centre de données, tant qu'une majorité des machines reste vivante et joignable (formellement, il tolère f pannes sur un total de 2f + 1 machines), et tant que le client peut joindre une machine connectée à cette majorité. Autrement dit, la panne d'une seule machine, ou la dégradation d'un seul lien réseau, n'affecte jamais la disponibilité globale, une propriété que les systèmes basés sur Raft n'offrent pas. Cloudflare précise ne pas viser la tolérance aux fautes byzantines (des acteurs activement malveillants dans le système), comme la plupart des systèmes de consensus grand public.

Comment fonctionne un cluster Meerkat

Concrètement, un service qui veut utiliser Meerkat demande un cluster de replicas. Chaque replica est connecté à tous les autres, participe à l'algorithme de consensus, et peut recevoir aussi bien des lectures que des écritures. Le développeur choisit les centres de données autorisés à héberger ses replicas, et Meerkat se charge du placement. Le client envoie sa requête (un get ou un put sur la base clé-valeur, par exemple) à n'importe quel replica du cluster, qui la traduit en un événement de journal (log event) puis le distribue à tous les autres replicas via l'algorithme de consensus. Tous les replicas finissent par maintenir exactement le même journal (un replica peut prendre du retard, mais n'enregistrera jamais une entrée différente des autres). Les lectures sont garanties de refléter l'état le plus à jour.

Un service encore interne, mais qui donne des idées

Meerkat reste un projet expérimental. Il est aujourd'hui pensé pour gérer de petites quantités d'état de plan de contrôle, comme l'information de leadership d'une base de données répliquée, et Cloudflare le garde volontairement interne pour l'instant. Ce billet est présenté comme le premier d'une série sur le sujet.

Pas d'accès direct pour les développeurs externes, donc, mais deux enseignements valent la peine d'être retenus si vous concevez vos propres systèmes distribués. D'abord, le choix d'un algorithme sans leader devient pertinent dès que votre système doit tenir sur un réseau étendu (multi-région, multi-cloud) où les latences sont imprévisibles : un simple Raft mal réglé peut transformer une panne locale en indisponibilité globale. Ensuite, Cloudflare a l'habitude de transformer ses briques internes en produits exploitables par ses clients, à l'image de Durable Objects ou Workers KV en leur temps. Rien n'indique aujourd'hui que Meerkat suivra ce chemin, mais c'est une évolution à surveiller si vous vous appuyez sur l'écosystème Cloudflare pour vos applications critiques.

Notre lecture chez CZSyn

Ce genre de billet technique, en apparence réservé aux ingénieurs infra, a un intérêt direct pour nos clients qui s'appuient sur Cloudflare comme CDN, WAF ou plateforme Workers : la fiabilité du plan de contrôle interne de Cloudflare, celui qui décide où sont placées les ressources et qui a le droit d'écrire où, conditionne directement la stabilité du réseau que vous utilisez au quotidien. Que Cloudflare documente publiquement avoir subi des incidents liés à des leaders Raft indisponibles, puis investisse un an d'ingénierie pour corriger le problème à la racine, est plutôt un bon signal de maturité opérationnelle.

Sur le plan technique, cette approche confirme une tendance que nous observons depuis plusieurs années dans la conception de systèmes distribués : le passage de mécanismes centrés sur un leader unique vers des architectures où chaque nœud peut progresser indépendamment. C'est plus complexe à implémenter, mais cela élimine une classe entière de pannes en cascade. Pour les équipes qui construisent leurs propres services multi-régions, même à petite échelle, la question mérite d'être posée avant de choisir par défaut un outil reposant sur Raft : votre réseau a-t-il vraiment le profil de latence stable pour lequel Raft a été pensé ?

Sources primaires

• Cloudflare Blog, James Larisch, Bob Halley, João Pedro Leite, « Introducing Meerkat: an experiment in global consensus », 8 juillet 2026.
• Cloudflare Blog, page d'accueil officielle, blog.cloudflare.com.