Quel cache pour quel problème ?
Une antisèche pour décider vite. Le critère n'est pas le cache le plus rapide, mais la couche à laquelle tu caches : HTTP, périphérie, applicatif ou devant l'appli entière.
Commence par le cache HTTP (en-têtes) et un CDN devant l'appli — gratuit, hors de ton code. Ajoute Redis seulement quand tu caches des données calculées ou des sessions.
Cache HTTP / en-têtes
Le cache gratuit, personne ne le code.
Choisir si : assets statiques, réponses cachables par CDN/navigateur, contrôle fin via Cache-Control/ETag.
Éviter si : données dynamiques propres à un utilisateur, besoin d'invalidation immédiate.
CDN (Cloudflare, Fastly) / cache en périphérie
Le cache au plus près de l'utilisateur.
Choisir si : contenu public, assets, pages peu personnalisées, réduire la latence géographique.
Éviter si : contenu très personnalisé par utilisateur, données sensibles à ne pas dupliquer en périphérie.
Redis / cache clé-valeur
La vitesse, structurée.
Choisir si : cache applicatif, sessions, résultats de requêtes coûteuses, structures de données (listes, sets).
Éviter si : cache purement HTTP/CDN où un simple en-tête suffit déjà.
Memcached / cache clé-valeur simple
Fait une chose, la fait bien.
Choisir si : cache simple d'objets, multi-thread natif, pas besoin de structures de données ni de persistance.
Éviter si : besoin de persistance, structures riches (listes/sets/pub-sub) → Redis fait plus.
Varnish / cache HTTP inversé
Un proxy dédié au cache.
Choisir si : cache de pages entières devant une appli, VCL pour logique de cache fine, fort trafic en lecture.
Éviter si : contenu très dynamique/personnalisé, équipe sans habitude du VCL.