Adapter le stockage en ligne à plus d’un milliard d’utilisateurs de ChatGPT (partie II)

Tous les produits OpenAI nécessitent un accès rapide et fiable aux données, assuré par notre plateforme de stockage, Habitat. Elle doit répondre en quelques millisecondes à plus d’un milliard d’utilisateurs répartis dans 40 régions géographiques. Notre infrastructure devait relever un défi extraordinaire : soutenir une croissance fulgurante et de nouveaux cas d’utilisation tout en améliorant la fiabilité, les performances et la rapidité du développement de produits. Pour y parvenir, il a fallu repenser la conception et l’exploitation de notre plateforme de stockage en ligne. Nous évaluions constamment les compromis selon cet ordre : devenir d’abord assez fiables pour le trafic produit critique, puis assez rapides pour les utilisateurs du monde entier, et enfin fonctionner efficacement à très grande échelle.

Cette série en deux parties explique comment nous avons fait évoluer Habitat, d’une simple bibliothèque cliente et d’une base de données à une plateforme de stockage distribuée mondialement donnant accès à plus de 500 pétaoctets de données. La partie I portait sur l’évolution d’Habitat d’un client Python à un service. Elle présentait aussi les techniques qui nous ont permis de pousser un service fondé sur Python bien au-delà de ce que beaucoup jugeraient raisonnable.

Dans ce billet, la partie II, nous expliquons comment nous avons fait évoluer le composant de stockage sous-jacent : Azure Cosmos DB. Grâce à une étroite collaboration avec l’équipe Azure, nous avons trouvé une approche multilocataire viable reposant sur des conteneurs cogérés, offrant d’excellentes performances en lecture à très grande échelle, partout dans le monde.

À mesure que les entreprises grandissent, les équipes d’infrastructure passent souvent de systèmes monolocataires à des systèmes multilocataires. Dans une architecture monolocataire, chaque équipe responsable d’une composante produit maintient son propre système. Cela limite les répercussions des incidents, clarifie les responsabilités et isole les charges de travail. À mesure que les équipes et les composantes produit se multiplient, cette approche devient coûteuse à exploiter. L’architecture monolocataire rend chaque équipe produit responsable de la planification de la capacité et entraîne souvent un surprovisionnement important.

À l’inverse, l’architecture multilocataire confie le contrôle à une équipe centralisée de bases de données, mieux outillée et plus expérimentée pour provisionner les ressources. Mais elle crée ses propres problèmes, notamment ceux des voisins bruyants, où un locataire consomme une part anormalement élevée des ressources au détriment des autres.

Pour Habitat, nous avons dû soupeser tous ces compromis afin de concevoir un système de stockage fiable et efficace à grande échelle. Aujourd’hui, Habitat est une couche de base de données multilocataire pour de nombreux produits OpenAI. Mais notre parcours a fait une boucle : d’un conteneur Azure Cosmos DB multilocataire, nous sommes passés à des conteneurs sous-jacents monolocataires, avant de revenir à un conteneur multilocataire par défaut. Notre parcours multilocataire dans Habitat n’en est qu’à ses débuts : nous prenons en charge de nombreux cas d’utilisation, mais avons pu reporter les investissements dans ce domaine en exploitant autant que possible les primitives intégrées d’Azure Cosmos DB.

Avant de retracer notre parcours avec Azure Cosmos DB, voici quelques notions de base :

• Un compte Azure Cosmos DB définit un ensemble de conteneurs et une politique de réplication

• Chaque conteneur est provisionné pour un certain débit, exprimé en unités de requête par seconde (RU/s)

• Les données de chaque conteneur sont réparties de façon classique selon une clé de partition logique spécifiée, avec des limites documentées de stockage et de débit par clé

• Azure Cosmos DB répartit les clés de partition logique sur un nombre inférieur de partitions physiques sous-jacentes, puis divise celles-ci lorsque le stockage dépasse un seuil ou que le conteneur a besoin de plus de partitions physiques pour soutenir le débit provisionné

Au départ, nous laissions passer toute la charge des clients, en comptant sur la limite annoncée de 10 k RU/s par clé de partition logique pour exercer une contre-pression. À nos débuts, nous n’utilisions aussi qu’un seul conteneur Azure Cosmos DB par défaut dans chaque compte. Cela fonctionnait assez bien, mais s’est avéré problématique pour plusieurs raisons :

En raison de nos premiers choix d’API, nous avions donné aux clients le contrôle direct du choix de la clé de partition logique. Nous avons donc de fréquentes collisions entre différents cas d’utilisation produit sur des clés de partition courantes, comme user_id ou workspace_id. Comme ces cas d’utilisation partageaient les limites Azure Cosmos DB des mêmes clés de partition logique, cette conception limitait le débit global pour un utilisateur donné.

Avant notre passage à Habitat et Azure Cosmos DB, un problème fréquent lors de la montée en charge de Postgres était qu’un grand nombre de requêtes provenant d’une organisation ou d’une clé très sollicitée — un locataire générant une charge disproportionnée — pouvait mettre hors service toute la base de données. Un effort collectif important a été consacré à la mise en cache de ces clés et à l’ajout de baux lors des défauts de cache, afin que la charge qui en résultait ne submerge pas la base de données sous-jacente.

Bien que les limites documentées de volume de données et de débit s’appliquent aux clés de partition logique, c’est en réalité au niveau de la partition physique qu’elles sont imposées. En pratique, les partitions logiques ne peuvent donc pas atteindre 10 000 RU/s. Elles partagent plutôt les limites de la partition physique avec toutes les autres clés de partition logique qui y sont colocalisées.

Des voisins bruyants pouvaient ainsi affecter de nombreuses clés de partition logique sans lien entre elles : des charges traitant les données de fonctionnalités de niche perturbaient les parcours essentiels de connexion et d’inscription.

La limite de débit d’une partition physique donnée varie aussi selon le débit total attribué au conteneur Azure Cosmos DB. Le débit provisionné du conteneur est réparti à peu près également entre ses partitions physiques.

À mesure que le volume de données augmente, les partitions physiques se divisent, ce qui accroît leur nombre total sans modifier le débit total provisionné. La limite de débit effective par partition diminue donc à mesure que le volume de données augmente.

Pour nos cas d’utilisation les plus gourmands en stockage, de type blob, cela crée un mode de défaillance où la seule croissance du stockage réduit la capacité de débit des charges actives, même si les taux de requêtes et l’utilisation restent stables.

Des conteneurs distincts aident à résoudre en partie ces limites de clés de partition et ces problèmes de voisins bruyants. Chaque conteneur distinct peut disposer de ses propres partitions physiques indépendantes. Seules les charges de ce conteneur peuvent alors être des voisins bruyants ou se chevaucher dans l’espace des clés de partition. En contrepartie, provisionner de nouveaux conteneurs entraîne des frais de gestion : chacun exige une planification individuelle de la capacité. Nous souhaitons donc créer des conteneurs uniquement lorsque la séparation par service ou par cas d’utilisation est pertinente.

Nous avons commencé à utiliser des conteneurs Azure Cosmos DB distincts pour les nouveaux cas d’utilisation les plus critiques nécessitant une forte isolation. Avec, en complément, un script gérant les partitions à faible capacité en synchronisant le débit total provisionné de chaque conteneur avec son nombre de partitions physiques, nous avons évité la plupart des problèmes rencontrés.

Toutefois, comme nous avions commencé avec un conteneur par défaut, de nombreux cas d’utilisation critiques existants y restaient malheureusement bloqués sans migration des données. Pour protéger les services critiques qui dépendaient encore des données du conteneur partagé par défaut, nous conseillions souvent aux équipes de créer des conteneurs distincts pour les nouveaux services ou les fonctionnalités majeures. Avec notre croissance, la pression sur le conteneur par défaut augmentait, tout comme les incidents en production. Nous avons commencé à provisionner des conteneurs pour tout nouveau service ou toute fonctionnalité importante, simplement pour éviter d’accroître la charge du conteneur par défaut.

Cela nous a évité de nombreuses pannes généralisées, limitant les répercussions à des dégradations de fonctionnalités ou de services. Cependant, les frais de gestion du provisionnement de nouveaux conteneurs ont fini par nous rattraper :

Dans l’ancien conteneur partagé par défaut, il était peu probable qu’un nouveau cas d’utilisation passant de 0 à 1 million de requêtes par seconde (QPS) modifie sensiblement l’utilisation totale. Dans un conteneur isolé, en revanche, un nouveau cas d’utilisation passant de 0 à 1 million de QPS pouvait représenter une charge 1 000 fois supérieure au niveau de référence issu des seuls essais internes.

Avec les conteneurs dédiés, les équipes devaient désormais penser à provisionner à l’avance le débit attendu pour leurs lancements. Les équipes produit déployaient souvent leurs fonctionnalités en production en oubliant d’augmenter la capacité à l’avance. Le jour du lancement, nous nous retrouvions en cellule de crise à tenter d’augmenter la capacité des conteneurs à la dernière minute.

Nous perdons ainsi un avantage essentiel du mélange des charges dans les systèmes multilocataires, au profit d’une meilleure isolation grâce à cette stratégie de conteneurs.

Au fil du temps, surveiller l’utilisation des conteneurs dédiés exigeait aussi une connaissance approfondie du produit pour savoir quand le trafic allait changer ou augmenter.

Nous pouvons fournir un script de plan de contrôle simple pour augmenter le débit provisionné de chaque conteneur selon les tendances de croissance. Mais sans croissance globale stable, bien dimensionner ces conteneurs impliquait de faire participer pratiquement toutes les équipes produit d’OpenAI à la planification de la capacité.

Cette approche n’a pas suivi la croissance organisationnelle, car l’attention portée au provisionnement Azure Cosmos DB variait considérablement d’une équipe responsable de service à l’autre.

Avec la croissance de l’organisation, ces problèmes opérationnels sont devenus difficiles à gérer à grande échelle. L’absence d’une équipe centrale unique chargée de la planification a conduit de nombreuses équipes à mal planifier. Nous sommes donc revenus à une solution multilocataire et avons collaboré étroitement avec l’équipe Azure pour corriger nos problèmes initiaux au moyen d’une architecture partagée :

Limiter d’abord le débit des clés les plus sollicitées empêche les voisins bruyants de consommer tout le débit disponible d’une partition physique. Cela réduit l’effet de voisin bruyant, où une seule clé très sollicitée peut avoir des répercussions sur l’ensemble du site.

La QoS par niveaux de requêtes empêche de même les charges hors ligne, comme les insertions en masse ou les extractions de données, d’utiliser tout le débit d’une partition physique. En attribuant une priorité moindre aux requêtes de ces charges, leur débit est limité en premier, ce qui évite de limiter celui des requêtes interactives plus prioritaires destinées aux utilisateurs finaux.

Azure Cosmos DB disposait déjà d’un mode sans serveur qui aurait résolu notre problème de partitions à faible capacité dans le mode provisionné. Il présentait toutefois un inconvénient majeur : il s’adaptait uniquement à l’utilisation du stockage et limitait l’utilisation des RU à 5 k RU/s par partition physique. Cela aurait résolu notre problème de partitions à faible capacité, mais nous aurait empêchés d’augmenter la capacité des cas d’utilisation gourmands en RU.

L’équipe Azure Cosmos DB a conçu pour nous un mode sans serveur amélioré permettant à chaque partition physique d’atteindre 10 k RU/s et ajoutant des divisions fondées sur l’utilisation des RU à celles fondées sur le stockage. Nous avons ainsi pu cesser de surveiller et de redimensionner manuellement les conteneurs.

Grâce à ces changements, nous avons pu revenir à un seul conteneur partagé. Cela a grandement simplifié la planification initiale et continue de la capacité pour les équipes produit, tout en préservant l’isolation entre les charges. Depuis, nous n’avons connu aucun incident de provisionnement ou de voisin bruyant, malgré l’accélération du développement de produits.

Quand les entreprises atteignent la taille d’OpenAI, les services gérés deviennent moins « gérés ». De nombreuses charges deviennent atypiques dans l’infrastructure du fournisseur infonuagique. OpenAI étant devenu l’un des plus grands utilisateurs d’Azure Cosmos DB, son exploitation efficace exigeait une approche différente : tests et tableaux de bord partagés, canaux directs entre équipes d’ingénierie et responsabilité conjointe des modes de défaillance qui n’apparaissent qu’à notre échelle. Aujourd’hui, notre plus grand compte Azure Cosmos DB stocke des dizaines de pétaoctets de données et traite plus de 20 millions de requêtes par seconde. À notre connaissance, nous sommes la seule entreprise à avoir déployé Azure Cosmos DB à cette échelle.

Fin 2024, une panne régionale a clairement montré pourquoi cette collaboration était nécessaire. Une panne de courant avait alors touché la région Azure principale de l’un de nos plus grands comptes Azure Cosmos DB. Lors du basculement qui a suivi, nous avons constaté qu’il faudrait plusieurs heures à nos plus grands comptes pour basculer vers une région secondaire, ce que ni notre équipe ni celle d’Azure Cosmos DB n’avaient testé à notre échelle.

Environ un mois plus tard, en faisant rebasculer ces comptes vers leur région d’origine, nous avons déclenché une autre panne grave. Un afflux massif de connexions vers la région d’origine a submergé sa passerelle Azure Cosmos DB. Une particularité de la gestion des basculements par le client Azure Cosmos DB en mode passerelle a amené tous les clients à établir immédiatement des connexions et à envoyer des requêtes à la région d’origine, même si seules certaines partitions physiques y étaient revenues.

À chaque panne, OpenAI et Azure ont appliqué leurs processus de gestion des incidents, identifié plusieurs causes fondamentales et déployé des correctifs. Mais ces pannes révélaient un problème systémique plus large lié aux méthodes d’exploitation et de test de notre équipe et de celle d’Azure Cosmos DB. Au départ, les services gérés nous permettaient d’avancer vite et de nous concentrer sur nos objectifs d’affaires. À grande échelle, les services gérés le sont moins et exigent une intégration poussée avec le fournisseur à tous les niveaux, de la conception à l’exploitation.

Aujourd’hui, les équipes d’ingénierie d’Habitat et d’Azure surveillent conjointement toutes les couches d’Habitat, de nos couches de service aux couches de stockage physique d’Azure Cosmos DB. Nous exploitons un compte Azure Cosmos DB hors production, mais de taille équivalente à celui de production, pour y tester les changements. Nous testons et améliorons ensemble les SDK et déterminons les pratiques exemplaires pour faire évoluer et dimensionner nos comptes Azure Cosmos DB. Nos équipes d’ingénierie communiquent directement par Teams. Nous avons même mis en place des moyens de nous alerter directement, sans passer par les niveaux de soutien.

Au cours de la dernière année, un important travail conjoint a amélioré l’évolutivité du plan de contrôle et de la passerelle d’Azure Cosmos DB : ajout de protections contre la surcharge et de mise en cache de diverses métadonnées Azure Cosmos DB dans la passerelle pour protéger leur partition; réduction de la pression exercée par notre parc de processus Python habitat-service grâce au regroupement et à une réutilisation accrue des connexions; colocalisation des charges de travail lorsque possible; et isolation des charges critiques des charges hors ligne au moyen de VPC distincts.

Ce niveau de collaboration technique a été essentiel à la stabilité de notre déploiement Azure Cosmos DB au cours de la dernière année. Tout système suffisamment grand ou critique exige ce type de travail d’équipe : décloisonner les responsabilités et travailler au-delà des frontières organisationnelles.

Comme indiqué dans la partie I, notre philosophie de base est la suivante : assurer le fonctionnement, accélérer, puis réduire les coûts. La fiabilité d’abord, puis les performances, puis l’efficacité. Habitat était devenu une infrastructure critique pour OpenAI; la première priorité était donc de le rendre fiable. À mesure que le système se stabilisait en 2025 et qu’OpenAI se développait à l’international, la latence est devenue la contrainte suivante pour les utilisateurs et les équipes produit.

Les capacités de calcul et de stockage se trouvaient souvent dans des régions différentes, ce qui rendait les requêtes interrégionales inévitables.

La latence variait considérablement selon l’emplacement des données et le lieu de traitement de la requête. Pour rendre les requêtes Habitat performantes, les développeurs de produits ajoutaient de la mise en cache côté client, regroupaient les requêtes, réduisaient les lectures et écritures en base de données et retiraient autant de travail que possible du chemin critique. Cela a mené à des conceptions de produits intéressantes, plus résilientes aux problèmes de base de données, mais a aussi complexifié les produits et ralenti les itérations. L’objectif d’Habitat — favoriser un développement rapide sans devoir comprendre la base de données — n’était donc pas atteint.

C’est une priorité majeure pour nous en 2026. Nous avons élaboré une stratégie à plusieurs niveaux pour optimiser les performances des lectures, qui représentent plus de 90 % des requêtes Habitat :

Nous disposons de plusieurs comptes Azure Cosmos DB dans différentes régions Azure du monde pour les utilisateurs ayant des exigences de résidence des données. Même sans exigences strictes de résidence des données, stocker les données près des utilisateurs améliore leur expérience en réduisant la latence.

En pratique, nous ne pouvons pas généraliser cette approche au-delà des cas liés à la résidence des données, car le placement est limité par la capacité physique du nuage. Vu la taille de nos ensembles de données, de nombreuses régions ne peuvent pas accueillir le volume de stockage massif requis pour leur part proportionnelle du trafic utilisateur.

Dans les régions où la capacité des centres de données, l’alimentation ou le refroidissement sont limités, nous devons parfois choisir : réserver de la capacité au stockage colocalisé pour réduire la latence d’Habitat, ou l’utiliser pour accroître le calcul au service des requêtes et acheminer les requêtes de stockage plus loin.

Les décisions de placement constituent donc souvent un compromis produit entre A) l’optimisation de la latence pour différents produits et groupes d’utilisateurs, et B) la capacité brute de stockage et de calcul.

Pour les charges les plus sensibles à la latence, comme les métadonnées d’authentification nécessaires à chaque requête, nous réduisons le temps aller-retour (RTT) entre le calcul et Habitat grâce à des comptes Azure Cosmos DB fortement répliqués dans de nombreuses régions secondaires. Certains comptes sont répliqués dans les 40 régions Azure où nous traitons du trafic; d’autres, dans au moins une région par continent.

Nous avons dû intégrer à Habitat, plus tôt que prévu, une couche transparente de déplacement et de routage des données pour déplacer des ensembles de données entre des comptes aux topologies de réplication différentes.

Toutefois, cette approche reste elle aussi contrainte par la capacité et se limite donc à quelques ensembles de données soigneusement sélectionnés.

Les charges d’Habitat sont très majoritairement axées sur la lecture : les applications récupèrent constamment des paramètres, des états et d’autres propriétés. Une part disproportionnée du trafic provient d’un ensemble de travail relativement petit de types fréquemment consultés. Le système se prête donc particulièrement bien à la mise en cache distribuée. Si la mise en cache améliore les performances d’une infrastructure monorégionale, ses gains se multiplient entre régions, où elle peut « masquer » la latence interrégionale.

Nous avons intégré à Habitat une couche de cache latéral distribué. Elle stocke une copie des objets et des arêtes récemment consultés sur des serveurs Valkey placés dans notre infrastructure près du lieu de traitement des requêtes utilisateur. Ces caches utilisent généralement une durée de vie (TTL) qui établit un compromis entre le taux de succès et l’obsolescence des données. Des TTL courts réduisent l’obsolescence, mais atténuent les gains du cache, car les éléments expirent vite et doivent être récupérés plus souvent. Des TTL plus longs améliorent le taux de succès, mais servent des données périmées plus longtemps, ce qui nuit à l’expérience utilisateur et rend le comportement du produit imprévisible.

Une autre approche consiste à exécuter des invalidations explicites lorsque l’application effectue des écritures sur les mêmes données sous-jacentes. Cela améliore considérablement la fraîcheur des données en cache, mais peut être difficile à mettre en œuvre correctement. Cette approche reste aussi soumise à divers cas limites, comme les défaillances partielles qui laissent le cache périmé. Les déploiements multirégionaux aggravent ces problèmes : les réseaux interrégionaux sont moins fiables, et le cache entre en concurrence avec la réplication du stockage sous-jacent. L’ajout de TTL borne l’obsolescence maximale, mais reste soumis au même compromis fondamental décrit plus haut.

Nous avons adopté une approche d’invalidation plus avancée, inspirée de systèmes comme TAO de Meta. Le cache intégré d’Habitat utilise la capture des modifications de données (CDC), via le flux de modifications d’Azure Cosmos DB, pour propager les invalidations mondialement en quelques secondes, avec un taux de succès élevé et peu d’obsolescence. Un service de notre infrastructure consomme ce flux et invalide les caches locaux lorsque les données sous-jacentes sont mises à jour. Cela provoque un défaut de cache à la lecture suivante, puis le cache est rempli avec la dernière version des données.

Nous avons aussi fortement réduit la latence en éliminant du surcoût dans le service Habitat lui-même, grâce à une réécriture en Rust, plus performant que le code Python d’origine.

Ensemble, ces changements ont réduit notre latence p50 globale en lecture, à l’échelle mondiale, d’environ 120 ms à environ 10 ms, soit un gain d’un facteur 12 depuis le début de nos efforts sur les performances en début d’année.

Si le cache a fortement réduit la latence médiane, les requêtes les plus lentes doivent encore récupérer des données non mises en cache dans le stockage sous-jacent, souvent dans des régions éloignées. À mesure que la capacité augmente et que nous améliorons l’efficacité du stockage, nous comptons relever un défi plus fondamental : placer dès le départ les données près de leur lieu d’accès.

Une CDC fiable et évolutive — qui propage les modifications de la base de données aux systèmes en aval — est essentielle bien au-delà de la stratégie de cache d’Habitat. Des millions de modifications capturées par seconde, dans des milliers de conteneurs et des millions de partitions, transitent par plus d’une centaine de rubriques Kafka. Elles alimentent aussi des index secondaires à cohérence éventuelle, des pipelines de déplacement de données, des analyses hors ligne et d’autres fonctionnalités produit en temps réel. Avec l’expansion mondiale de notre infrastructure sous-jacente, l’écoute des modifications de lignes est devenue de plus en plus complexe. Pour enregistrer une fonction de rappel à exécuter chaque fois que des lignes de son type changent, un client doit notamment déterminer quels comptes et conteneurs Cosmos hébergent ses données, quel déploiement CDC les écoute dans chaque région, puis dimensionner correctement le parc de processus de travail CDC, Kafka et son consommateur. Notre plateforme CDC vise à masquer cette complexité aux développeurs de produits. Elle propose une interface simple où les clients enregistrent une fonction à appeler pour leurs lignes modifiées; nous gérons toute l’infrastructure et la mise à l’échelle.

Un plan de contrôle interne vérifie en continu que tous les conteneurs requis sont capturés, choisit les régions Cosmos à lire et répartit efficacement le travail entre des milliers de processus dans plusieurs régions géographiques. L’utilisation de régions de réplication et de lectures du flux moins prioritaires protège le trafic Habitat sensible à la latence des charges de capture en arrière-plan. Dans un parc aussi vaste, les arrêts de processus, les problèmes de conteneurs, les erreurs du magasin de baux, les configurations invalides et les défaillances de destination sont constants. Nous avons renforcé le cycle de vie des processus CDC et la gestion des baux, isolé les défaillances entre flux et ajouté des protections pour les changements de configuration et les déploiements. Nous utilisons des files d’attente de lettres mortes pour éviter qu’un échec permanent de livraison bloque la tête de file. Nous tolérons les pannes régionales en basculant les lecteurs vers d’autres régions Cosmos. À notre échelle, nous avons même dû modifier le SDK CDC d’Azure pour rendre ses points de contrôle plus efficaces, en les regroupant en mémoire et en ne les écrivant que périodiquement.

Même si l’utilisation interne d’Azure Cosmos DB par Habitat est complexe, sa valeur a toujours été de masquer les détails d’infrastructure aux développeurs pour accélérer le développement de produits. Notre plateforme CDC suit le même principe.

Une petite équipe a pu soutenir une plateforme de stockage en forte croissance en gardant l’API de stockage volontairement restreinte, en continuant à faire évoluer le service Python et en priorisant les défis techniques les plus urgents. Nous avons privilégié la fiabilité du trafic produit critique, puis les performances en lecture pour les utilisateurs du monde entier, et enfin l’efficacité opérationnelle à grande échelle. Cette approche a permis une croissance rapide et de nouveaux cas d’utilisation, tout en améliorant la fiabilité, les performances et la rapidité du développement de produits.

Pour adapter Habitat et le stockage des conversations au prochain milliard d’utilisateurs, nous devons surmonter la difficulté de répliquer nos données dans notre infrastructure à une échelle encore plus grande. Pour anticiper ce besoin, nous développons à l’interne un système de stockage en ligne sur mesure à l’échelle de l’exaoctet, optimisé pour les types de données volumineux d’Habitat. Ce système en développement combine le cœur RocksDB Cloud de Rockset avec une réplication fondée sur Raft. Il met en œuvre le même modèle documentaire qu’Azure Cosmos DB, mais utilise un stockage désagrégé et une réplication physique pour réduire la capacité flash requise, au prix d’un nombre maximal de requêtes par seconde inférieur.

Si ces projets d’infrastructure de données à une échelle de pointe vous intéressent, consultez nos postes ouverts⁠.