Comment un serveur MySQL unique, situé en Europe, peut-il répondre en quelques millisecondes à un cache d’objets consulté par des visiteurs au Japon, au Brésil ou en Afrique du Sud ? Il ne le peut pas, structurellement. Un réseau de sites à audience mondiale a dû répondre à cette contrainte en construisant un pont entre l’API de cache d’objets standard de WordPress et Cloudflare Workers KV, un magasin clé-valeur répliqué sur l’ensemble des points de présence du réseau Cloudflare.
Ce que l’API de cache d’objets WordPress attend
WordPress expose une API de cache d’objets entièrement agnostique du backend qui la sert, via les fonctions wp_cache_get(), wp_cache_set(), wp_cache_delete() et leurs équivalents par groupe. N’importe quel mécanisme de stockage clé-valeur peut servir de backend, à condition de fournir un fichier object-cache.php à la racine du dossier wp-content qui implémente ces fonctions attendues par le cœur.
Workers KV, de son côté, est pensé pour de la lecture massivement répliquée à travers le réseau Cloudflare, avec une propagation des écritures qui prend jusqu’à 60 secondes pour atteindre l’ensemble des points de présence. C’est cette asymétrie lecture/écriture qui a dicté toute l’architecture du pont.
Arborescence du pont mis en place
wp-content/
├── object-cache.php (implémente l'API cache WordPress)
├── mu-plugins/
│ └── kv-bridge/
│ ├── kv-bridge-client.php (appels vers l'API REST Workers KV)
│ ├── kv-bridge-queue.php (file d'attente locale d'écritures)
│ └── kv-bridge-fallback.php (repli vers Redis local si KV indisponible)
workers/
├── kv-read-proxy.js (Worker exposé à l'edge, lecture rapide)
└── kv-write-relay.js (Worker qui absorbe les écritures en lot)Le chemin de lecture
Chaque appel à wp_cache_get() interroge d’abord un cache Redis local à très courte durée de vie (quelques secondes), puis, en cas d’absence, appelle le Worker kv-read-proxy.js exposé au plus près du point de présence Cloudflare qui traite la requête. Ce Worker lit directement dans Workers KV, sans repasser par le serveur d’origine, ce qui explique la latence de lecture mesurée à 40 ms en moyenne depuis un point de présence proche, contre 280 ms si la même donnée avait dû être récupérée depuis le serveur d’origine en Europe.
// object-cache.php, extrait simplifié
function wp_cache_get( $key, $group = '' ) {
$cle_complete = kv_bridge_construire_cle( $key, $group );
$valeur = kv_bridge_redis_local_get( $cle_complete );
if ( false !== $valeur ) {
return $valeur;
}
return kv_bridge_client_lire_kv( $cle_complete );
}Le chemin d’écriture, plus délicat
Écrire directement dans Workers KV à chaque wp_cache_set() aurait introduit une latence d’écriture incompatible avec le rythme des pages générées côté serveur d’origine. Le pont maison écrit donc d’abord dans le cache Redis local, immédiatement disponible pour l’origine elle-même, puis empile l’écriture dans une file d’attente locale traitée en arrière-plan par une tâche WP-Cron courte, qui envoie les écritures groupées vers le Worker kv-write-relay.js toutes les quelques secondes.
- Les écritures fréquentes (compteurs, sessions courtes) restent gérées par Redis local, jamais propagées vers Workers KV.
- Seules les données à forte valeur de lecture distribuée (fragments de page, résultats de requêtes coûteuses peu volatiles) sont propagées vers l’edge.
- Un indicateur de fraîcheur accompagne chaque valeur stockée dans KV, pour que les Workers de lecture sachent si une valeur récente n’a peut-être pas encore fini de se propager.
Ce qu’il a fallu accepter comme compromis
Un cache distribué à l’échelle mondiale n’est jamais parfaitement cohérent à l’instant T. Le choix n’est pas entre cohérence et absence de cohérence, mais entre quelles données peuvent tolérer un délai de propagation et lesquelles ne le peuvent pas.
Les données sensibles à la fraîcheur immédiate (statut de commande, panier en cours) ont été explicitement exclues du pont vers Workers KV et restent servies depuis Redis local ou directement depuis la base de données, selon la criticité. Seul le contenu éditorial et les fragments de rendu peu volatils transitent par ce pont.
Sécurité des clés d’accès
La gestion des jetons d’authentification vers l’API Cloudflare, indispensable au fonctionnement du pont, relève d’un chantier distinct que cet article ne couvre volontairement pas ; elle mérite un traitement dédié tant les implications de sécurité dépassent le seul sujet de la performance.
Pour la suite
Ce pont reste un développement maison, pas une solution packagée : sa maintenance suppose une équipe capable de surveiller à la fois le comportement de l’API de cache WordPress et celui de l’infrastructure Cloudflare Workers. Pour un réseau à audience réellement mondiale, ce coût d’ingénierie s’est révélé largement compensé par la latence de lecture obtenue, très inférieure à ce qu’un cache centralisé en Europe aurait jamais pu offrir.
