Un cache peut-il faire consommer plus de mémoire qu'il n'en fait gagner ?

Oui, et c'est un cas que je vois revenir. Si vous cachez des clés trop variées (une entrée par combinaison de filtres d'une page de recherche, par exemple), le cache enfle sans jamais resservir deux fois la même entrée. Vous payez la RAM et le coût de stockage pour un taux de réutilisation proche de zéro. Avant de cacher quoi que ce soit, regardez le rapport entre le nombre de clés distinctes et le nombre de lectures : s'il est mauvais, vous fabriquez un dépotoir, pas un cache.

Que se passe-t-il quand le cache tombe en panne en production ?

Tout doit continuer à fonctionner, plus lentement. C'est un point qu'on oublie de tester. Si votre code part du principe que la donnée est toujours dans le cache et plante quand elle n'y est pas, vous avez transformé une optimisation en point de défaillance unique. Le réflexe : traiter l'absence comme le cas normal (on recalcule, on repeuple), et vérifier ce comportement en coupant volontairement le cache sur un environnement de test.

Et l'effet de troupeau quand une entrée populaire expire ?

Quand une clé très lue arrive à expiration, toutes les requêtes qui la demandaient tombent en même temps sur le calcul derrière, qui n'est plus protégé. Sur une donnée chère à produire, ça suffit à mettre la base à genoux pendant quelques secondes. On s'en prémunit avec un verrou (une seule requête recalcule, les autres attendent) ou en repeuplant l'entrée avant qu'elle expire. C'est rarement nécessaire au début, mais le jour où ça mord, c'est violent et difficile à diagnostiquer.

Comment je m'aperçois qu'une entrée de cache est corrompue ou périmée par erreur ?

Versionnez la clé. Au lieu de cacher sous `produit:42`, cachez sous `produit:v3:42`. Le jour où vous changez la forme de la donnée ou que vous suspectez une entrée pourrie, vous incrémentez le numéro de version dans la configuration : l'ancien jeu de clés devient inatteignable et se purge tout seul, sans avoir à vider le cache à la main ni à redémarrer Redis. C'est l'invalidation d'urgence la plus propre que je connaisse.

Mettre en cache sans tout casser : quoi, où, combien de temps

On répète que le cache rend une application rapide. C’est faux, et la nuance n’est pas qu’académique : un cache ne vous fait gagner aucune milliseconde de calcul. Il évite simplement de refaire un calcul que vous avez déjà fait. Si votre lenteur vient d’une requête mal écrite ou d’un traitement intrinsèquement coûteux, le cache la planque derrière un voile tant que la donnée ne change pas. Et il vous la rend en pleine figure la première fois qu’elle change. Garder ça en tête change l’ordre dans lequel on travaille.

Un cache n’accélère pas, il supprime un calcul redondant : on cible ce qui est lu souvent et change rarement, et on écrit la règle d’invalidation avant la première ligne de code, parce que décider quand jeter la valeur concentre presque tout le travail.

Mon ordre de travail, quand j’arrive sur le sujet, ne varie pas.

Je mesure avant de cacher quoi que ce soit. Cacher une donnée consultée trois fois par jour ne rapporte rien ; cacher un calcul lourd appelé à chaque page change la vie. Le bon candidat se reconnaît à deux traits : il est lu souvent, il bouge rarement. Une configuration, un catalogue, le résultat d’une agrégation stable. Tant que je n’ai pas les chiffres de lecture sous les yeux, je ne décide rien.
Je choisis l’étage en partant de l’utilisateur. La mémoire locale du processus, un service partagé comme Redis, le cache HTTP qui range des réponses entières, le navigateur ou un CDN en bout de chaîne (un réseau de serveurs répartis géographiquement qui sert le contenu au plus près du visiteur) : chaque niveau a sa portée et sa durée de vie.

Plus je me rapproche de l’utilisateur, plus la lecture est rapide, mais plus l’invalidation devient difficile à propager. Je vais aussi loin que le métier le tolère, pas plus.

J’écris la règle d’invalidation avant la première ligne de code. C’est l’étape qu’on saute, et c’est celle qui fait mal. Deux options seulement. Soit l’entrée se périme toute seule après une durée fixée, et il faut caler cette durée sur le rythme réel de la donnée. Soit je la vide explicitement à chaque écriture qui la concerne, ce qui donne le contrôle exact contre une rigueur de tous les instants. Dans la plupart des cas, l’expiration automatique suffit. Mais le choix se fait maintenant, pas dans trois semaines.
Je note ce que je cache et la règle qui le vide. Une ligne par entrée, quelque part dans le dépôt. Ça paraît bureaucratique jusqu’au jour où quelqu’un d’autre doit comprendre pourquoi un prix promo s’affiche encore.

Sur ce dernier point, j’ai un souvenir précis. Client e-commerce, il y a deux ou trois ans : une promotion qui s’arrêtait à minuit restait visible le lendemain midi. Le cache HTTP était calé sur 24 heures par quelqu’un qui avait quitté la boîte, et personne n’avait relié cette durée au calendrier des promos. Le visiteur lent qui râle, on le récupère. Celui à qui on affiche un faux prix, lui, passe commande — et c’est le service client qui ramasse.

Alors quand je pose une durée d’expiration, j’inscris à côté, en commentaire, la raison du chiffre. Pas « 3600 », mais « 1 h, parce que le catalogue est réindexé toutes les heures à la minute 5 ».

Mettre en cache sans tout casser : quoi, où, combien de temps

À lire aussi

Questions fréquentes