Stratégies de cache pour les applications réelles

Le cache est la façon la moins chère d'acheter de la performance, et la plus rapide d'introduire des bugs subtils et épuisants si vous l'utilisez sans rigueur. La célèbre boutade selon laquelle « il n'existe que deux problèmes difficiles en informatique : l'invalidation de cache et le nommage des choses » a une raison d'être. Bien fait, le cache réduit drastiquement la latence et la charge. Mal fait, il sert des données périmées à vos utilisateurs et érode leur confiance. Voici comment le mettre en place de façon délibérée.

Cacher au bon niveau

Une requête traverse plusieurs endroits où vous pouvez mettre des données en cache, chacun absorbant un type de travail différent :

• Cache client / navigateur. Les en-têtes HTTP (Cache-Control, ETag) permettent au navigateur d'éviter entièrement les requêtes pour les ressources statiques. Gratuit et redoutablement efficace.
• Cache CDN. Un CDN sert des réponses mises en cache depuis la périphérie, au plus près des utilisateurs. Idéal pour les fichiers statiques et les réponses API pouvant être cachées.
• Cache applicatif. Un store en mémoire comme Redis conserve les résultats calculés, les données de session et les lignes chaudes de la base de données pour éviter de les recalculer ou de les refetcher.
• Cache base de données. La mise en cache des résultats de requêtes et les vues matérialisées réduisent les requêtes coûteuses répétées.

La meilleure stratégie combine généralement plusieurs couches. Une requête qui n'atteint jamais votre serveur est plus rapide et moins coûteuse qu'une requête que vous servez rapidement.

Choisissez un pattern adapté à vos données

Pour le cache applicatif, le pattern le plus courant et le plus fiable est le cache-aside : à la lecture, on vérifie d'abord le cache ; en cas de miss, on charge depuis la base de données, on stocke le résultat dans le cache, puis on le retourne. C'est simple et vous garde maître de ce qui est mis en cache et pour combien de temps.

Définissez un TTL (time to live) sur chaque entrée : ainsi, même si la logique d'invalidation présente une lacune, les données périmées expirent d'elles-mêmes. Un TTL court est un filet de sécurité — il borne l'étendue des dégâts possibles.

L'invalidation est la partie difficile, anticipez-la

Les données périmées sont le prix à payer pour le cache, et tout l'art consiste à les gérer. Quelques tactiques pour éviter les problèmes :

1. Privilégiez l'expiration à l'ingéniosité. Un TTL court est souvent plus simple et plus sûr qu'une logique d'invalidation complexe, et il échoue gracieusement.
2. Invalidez à l'écriture. Lorsque des données changent, évictez ou mettez à jour la clé de cache concernée dans la même opération.
3. Nommez et versionnez vos clés afin de pouvoir invalider toute une catégorie d'un coup et d'éviter les collisions.

Posez-vous une question directe pour chaque valeur mise en cache : dans quelle mesure cette donnée peut-elle être erronée, et pendant combien de temps, avant de nuire à un utilisateur ? Un catalogue produits peut supporter quelques secondes de retard ; un solde de compte, non. Laissez cette réponse guider vos TTLs.

Ne mettez pas en cache ce qui n'en a pas besoin

Le cache ajoute une pièce mobile, et les pièces mobiles tombent en panne. Avant d'ajouter un cache, confirmez que vous avez réellement un chemin critique qui mérite d'être optimisé — mesurez d'abord. Parfois, la bonne solution est un index ou une meilleure requête, pas une couche supplémentaire à maintenir en cohérence. Ne mettez jamais en cache des données hautement personnalisées ou sensibles du point de vue de la sécurité dans une couche partagée comme un CDN, où un utilisateur pourrait recevoir la réponse d'un autre.

Ajoutez les couches progressivement

Commencez par les gains faciles : des en-têtes HTTP corrects et un CDN pour les ressources statiques. Ajoutez Redis pour les calculs véritablement coûteux et les données chaudes à mesure que la charge augmente. Introduisez chaque couche uniquement lorsque vous pouvez désigner la métrique qu'elle améliore. Le cache doit être un scalpel appliqué à des goulots d'étranglement mesurés, non une couverture que vous jetez sur toute l'application en espérant que ça suffise.

Si votre application est lente et que vous ne savez pas quelle couche mettre en cache, parlez-nous-en.