Une clé de cache très sollicitée expire et votre base de données s'écroule. Que s'est-il passé, et comment l'évitez-vous ?

C'est une ruée sur le cache, parfois appelée thundering herd. Des milliers de requêtes concurrentes ratent le cache au même instant et recalculent toutes la même valeur. Corrigez avec un verrou single flight pour qu'un seul worker recalcule pendant que les autres attendent ou servent des données périmées. Ajoutez du jitter aux TTL pour que les clés n'expirent pas ensemble, rafraîchissez les clés chaudes en arrière-plan avant expiration, et servez du périmé en cas d'erreur.

C'est une ruée. La clé expire, dix mille requêtes en vol ratent le cache simultanément, et elles exécutent toutes la même requête coûteuse, donc la base voit dix mille copies d'une requête qu'elle voit normalement une fois par minute. Le premier correctif, c'est le regroupement : un verrou single flight dans le cache fait qu'un seul worker recalcule et que tous les autres attendent ce résultat ou reçoivent la valeur périmée. On a utilisé un verrou Redis SETNX avec un TTL court pour ça, et la charge base sur ce chemin a chuté d'environ deux ordres de grandeur. Par-dessus, j'ajoute du jitter à chaque TTL, donc au lieu de 300 secondes pile c'est 300 plus ou moins 10%, ce qui décorrèle les expirations entre clés. Pour les clés vraiment chaudes, je préfère le recalcul anticipé probabiliste, où une requête proche de la fin du TTL rafraîchit en arrière-plan tout en servant encore la valeur en cache. Et je mets toujours les résultats négatifs en cache, sinon une ligne absente devient une boucle de requêtes sans limite.