Stratégies de Caching : de Redis aux CDN

Le cache est partout

Le caching est la technique d'optimisation la plus efficace en informatique. Un cache bien placé peut réduire la latence de 100x et le coût infrastructure de 10x. Mais un cache mal géré introduit des bugs de cohérence insidieux. "There are only two hard things in CS: cache invalidation and naming things."

Les couches de cache

Un système moderne utilise plusieurs niveaux de cache, du plus proche du client au plus proche de la donnée.

Client
  └─ Browser Cache (localStorage, Service Worker)
      └─ CDN Edge Cache (CloudFlare, CloudFront)
          └─ API Gateway Cache
              └─ Application Cache (Redis, Memcached)
                  └─ Database Query Cache
                      └─ OS Page Cache (mmap, disk buffer)

Patterns de caching

Il existe quatre patterns principaux de caching applicatif. Chacun a ses forces et ses compromis.

• Cache-Aside (Lazy Loading) : l'app vérifie le cache, si miss → lit la DB → écrit dans le cache. Simple, risque de données stale.
• Read-Through : le cache est responsable de charger depuis la DB en cas de miss. L'app ne parle qu'au cache.
• Write-Through : chaque écriture passe par le cache PUIS la DB. Cohérence forte mais latence d'écriture accrue.
• Write-Behind (Write-Back) : écriture dans le cache immédiate, flush asynchrone vers la DB. Ultra-rapide mais risque de perte de données.

Cache Invalidation

Le vrai défi du cache est l'invalidation : s'assurer que les données en cache restent cohérentes avec la source de vérité. Il n'existe pas de solution universelle — chaque stratégie est un compromis entre fraîcheur et performance.

• TTL (Time-To-Live) : le cache expire après un délai fixe. Simple mais données potentiellement stale.
• Event-based invalidation : un événement (write, update) déclenche la suppression du cache. Frais mais complexe.
• Version-based : chaque entrée a une version, le client vérifie si sa version est à jour. Utilisé par les ETags HTTP.
• Purge sélectif : invalider uniquement les clés affectées par une mutation. Le plus précis mais le plus complexe.

Redis en production

Redis est le cache applicatif le plus populaire. En production, la configuration par défaut ne suffit pas. Il faut penser à la persistance, au clustering et à l'éviction.

• Choisir une politique d'éviction : allkeys-lru pour un cache général, volatile-ttl pour des données avec expiration
• Activer la persistance AOF pour ne pas perdre le cache au redémarrage
• Utiliser Redis Cluster pour la scalabilité horizontale (>25GB de données)
• Monitorer le hit ratio — un ratio <90% indique un problème de sizing ou de stratégie
• Séparer les caches par domaine (prefix keys) pour faciliter l'invalidation sélective