Cloudflare KV : ce que signifie une distribution mondiale lorsque vous devez écrire

Cloudflare KV est vendu comme un magasin distribué à l'échelle mondiale et cette description est techniquement correcte. Ce qu'il laisse de côté, c'est que « distribué à l'échelle mondiale » s'applique entièrement aux lectures et seulement partiellement aux écritures - avec un délai allant jusqu'à 60 secondes qui change tout sur la façon dont vous devez l'utiliser.

Lorsque vous écrivez une clé sur KV, l'écriture est envoyée à un magasin central. À partir de là, il se propage à tous les points de présence Cloudflare, soit plus de 300 PoP répartis dans le monde. Cette propagation n'est pas instantanée. La documentation officielle indique jusqu'à 60 secondes pour que tous les PoP reçoivent la nouvelle valeur. Pendant cette fenêtre, un Worker exécuté à Francfort peut renvoyer l'ancienne valeur tandis qu'un Worker à São Paulo voit déjà la nouvelle. Deux Workers dans la même région peuvent diverger si l'un d'eux n'a pas encore reçu la mise à jour.

C’est la cohérence éventuelle. Cloudflare documente clairement ce comportement, mais l'expression « distribué à l'échelle mondiale » est suffisamment séduisante pour que de nombreuses équipes ne lisent pas cette partie avant d'avoir débogué un bug en production.

Que se passe-t-il lors d'une lecture

La lecture en KV comporte deux chemins, et la différence entre eux est importante pour la latence. Lorsqu'un Worker effectue env.MY_KV.get('chave'), le runtime vérifie si cette clé est mise en cache dans le PoP qui traite la requête. Si c'est le cas - et la plupart des touches de raccourci le seront - la lecture revient en moins d'une milliseconde, directement à partir de la mémoire PoP. C'est la voie heureuse et c'est ce qui rend KV exceptionnellement rapide pour les lectures.

Si la clé n'est pas mise en cache dans ce PoP — parce qu'il s'agit d'une nouvelle clé, parce qu'elle a été écrite récemment et ne s'est pas encore propagée, ou parce que le PoP n'a tout simplement pas reçu cette entrée — le moteur d'exécution recherche dans le magasin central. Cela ajoute environ 20 ms. Ce n'est pas dramatique, mais c'est mesurable, et vous verrez ce chiffre apparaître en trace lorsque la clé sera froide.

Le détail qui surprend : il n’y a aucune garantie de lecture-écriture. Vous écrivez une clé et essayez immédiatement de la lire dans la même invocation Worker. La lecture peut renvoyer la valeur précédente. Ce comportement est documenté et intentionnel : c'est une conséquence directe de l'architecture de mise en cache PoP. Si vous avez besoin de lecture et d'écriture, KV n'est pas le bon outil pour ce flux.

Pour quelle charge de travail le KV a-t-il été construit

L’architecture KV prend tout son sens lorsqu’on connaît le problème qu’elle résout : des données écrites à basse fréquence et lues à très haute fréquence. Le modèle économique renforce cette tendance. Les lectures coûtent 0,50 $ par million après les 10 premiers millions mensuels gratuits. Les inscriptions coûtent 0,50 $ par million après le premier million gratuit. Dans le niveau gratuit, vous disposez de 100 000 lectures par jour et de seulement 1 000 écritures par jour.

Le coût et les limites pointent vers la même charge de travail : écrire peu, lire beaucoup. Les indicateurs de fonctionnalités sont l’exemple canonique. Un fichier JSON avec des indicateurs de produit change au maximum quelques fois par jour. Mais il est lu à chaque demande de chaque travailleur dans chaque PoP du monde. Une propagation de 60 secondes est acceptable pour un drapeau : vous n'avez pas besoin que tous les utilisateurs de la planète voient l'élément à la même milliseconde. Le nombre de lectures, potentiellement des milliards par mois, est mis en cache à un coût minime.

Le même raisonnement s'applique aux modèles HTML rendus, à la configuration des applications, aux données de catalogue avec une faible fréquence de mise à jour et aux jetons de session avec une durée de vie définie. Vous écrivez une fois, lisez des dizaines de milliers de fois, et KV vous offre cela avec une latence de cache.

Où KV va-t-il vous trahir

Toute charge de travail nécessitant une cohérence immédiate produira des bugs lorsqu’elle sera implémentée sur KV. Le cas le plus courant est une session utilisateur avec un état mutable. L'utilisateur se déconnecte ; vous écrivez le drapeau de session invalide en KV ; dans les 60 secondes suivantes, un autre PoP peut toujours authentifier les demandes avec l'ancien jeton car il n'a pas reçu la mise à jour.

Les compteurs précis sont un autre point d’échec. KV n'a pas d'opérations atomiques - il n'y a pas de comparaison et d'échange, il n'y a pas d'incrément atomique. Deux travailleurs lisant simultanément le même compteur liront la même valeur, incrémenteront indépendamment et l'un des incréments sera perdu. Pour les compteurs limiteurs de débit qui doivent être précis, KV n'est pas le bon outil. Des objets durables existent pour ce cas.

Les données qui changent par requête ne correspondent pas non plus. Si chaque réponse à l'utilisateur modifie une valeur du KV, vous payez 0,50 $ par million d'écritures dans un volume qui peut être gigantesque, avec une latence d'environ 150 ms par écriture pour confirmation dans le magasin central, plus un délai de propagation. Le coût évolue d'une manière qui n'a pas de sens économique, et la latence d'écriture apparaîtra dans la queue p99 de vos requêtes.

Pour une cohérence immédiate par clé avec une faible latence d'écriture, D1 avec l'API Sessions est le chemin actuel de Cloudflare. Pour les états partagés qui nécessitent des opérations atomiques, Objets durables.

Le modèle de coût sans illusions

Le niveau gratuit est généreux pour l’expérimentation mais étroit pour la production de n’importe quel volume. 100 000 lectures par jour équivalent à un peu plus d'une requête constante par seconde — une application réelle avec un trafic raisonnable dépasse ce chiffre en quelques minutes.

Dans le niveau payant, ce qui change, c'est que les lectures sont pratiquement gratuites à grande échelle. 0,50 $ par million de lectures est suffisamment bon marché pour ne pas apparaître comme une ligne pertinente sur la facture si votre charge de travail est correctement chargée en lecture. Écrit à 0,50 $ par million, avec 1 million gratuit par mois, couvre la plupart des normes et indicateurs de configuration sans frais importants.

Ce qui pourrait vous surprendre, c'est le stockage : 0,50 $ par Go-mois en plus du premier Go gratuit. Pour les petites valeurs — configuration JSON, tokens, flags — vous toucherez difficilement cette limite. Pour ceux qui envisagent de stocker des binaires de taille considérable en KV (la limite par valeur est de 25 Mo), le coût de stockage commence à apparaître. Pour les fichiers volumineux, R2 à 0,015 $/Go est plus logique.

Ce que KV résout bien et ce qu'il ne résout pas

KV est un outil de lecture performant avec écriture occasionnelle. Lorsque vous optez pour ce modèle, il offre une latence inférieure à la milliseconde pour les lectures à chaud, une distribution mondiale automatique sans configuration de réplication et un modèle de tarification qui favorise les lectures de volumes massifs.