Une clé de cache populaire expire et des centaines de requêtes frappent la base d'un coup. Comment évitez-vous ça ?

Évitez la ruée avec du single flight : la première requête en échec de cache prend un verrou court et recalcule pendant que les autres attendent brièvement ou servent la valeur périmée. Combinez ça avec du stale while revalidate, pour qu'une entrée expirée soit encore servie pendant qu'un rafraîchissement tourne en arrière-plan, et ajoutez du jitter aux durées de vie pour que les clés créées ensemble n'expirent pas ensemble. Pour les clés chaudes connues, rafraîchissez de façon proactive avant l'expiration.

Le motif, c'est une ruée : une clé chaude expire et toutes les requêtes concurrentes échouent au même instant, donc elles exécutent toutes la même requête coûteuse. La correction de base, c'est le single flight, où le premier échec acquiert un verrou de courte durée sur la clé et fait le travail, et tous les autres attendent le résultat ou obtiennent brièvement la valeur périmée. J'associe ça à une expiration souple : je stocke une date logique de rafraîchissement dans la valeur et je garde la durée de vie dure plus longue, donc une entrée dépassant sa date de rafraîchissement est encore servie pendant qu'un travailleur la recalcule en arrière-plan. Les utilisateurs ne voient jamais la latence. Ensuite le jitter, parce que si un déploiement préchauffe mille clés avec la même durée de vie de cinq minutes, elles expirent ensemble et j'obtiens la ruée sur tout le cache d'un coup. La question plus large qui suit, c'est ce qui se passe quand le cache est complètement vide, après un redémarrage ou une bascule. Je veux que la base y survive, alors je fais au moins une fois un test de charge avec le cache désactivé.