Caches applicatifs : cache-aside, TTL et invalidation

Ce que c'est

Cache-aside (chargement paresseux) : l'application recherche une clé dans le cache ; en cas d'absence (miss), elle lit la source de vérité, stocke la valeur avec une durée de vie (TTL), et la renvoie. Les écritures passent par la source et soit suppriment l'entrée du cache (invalidation), soit l'écrasent (write-through). Le cache contient des données dérivées et peut être perdu à tout moment.

Pourquoi c'est important

Les caches réduisent la charge et la latence, mais une entrée périmée servie après une écriture est un bug d'exactitude difficile à reproduire. La stratégie d'invalidation est une décision de conception, pas une idée après coup.

Comment l'appliquer

• Décider de la péremption acceptable par classe de données et fixer les TTL en conséquence ; un TTL court borne simplement les dégâts.
• À l'écriture, supprimer les clés concernées plutôt que de les mettre à jour ; la suppression est idempotente et évite les situations de concurrence entre écrivains simultanés.
• Inclure une balise de version ou de schéma dans la clé (user:v3:123) afin que les déploiements qui changent la forme des valeurs ne lisent pas d'anciennes entrées.
• Se protéger des ruées (stampedes) : en cas d'absence pour une clé très sollicitée, laisser une seule requête remplir le cache pendant que les autres attendent brièvement ou reçoivent des données légèrement périmées.
• Mettre en cache les résultats négatifs (« introuvable ») avec un TTL court si les recherches de clés absentes sont fréquentes.
• Mesurer le taux de succès (hit ratio) et la charge sur la source ; un cache jamais atteint coûte de la latence à chaque absence.

Pièges

Mettre en cache des données propres à un utilisateur sous une clé partagée. Une invalidation qui omet les clés dérivées (listes, comptages) quand un seul objet change. Traiter le cache comme un stockage durable. Un décalage d'horloge entre les hôtes qui fixent le TTL et ceux qui le vérifient.

La situation de concurrence entre suppression et repeuplement

L'invalidation à l'écriture n'est pas exempte de situation de concurrence (race) : un lecteur peut charger l'ancienne valeur depuis la source juste avant qu'une écriture ne se valide, puis la stocker dans le cache après la suppression effectuée par l'écrivain, laissant des données périmées jusqu'à l'expiration. Borner les dégâts avec des TTL courts, ou éviter la situation de concurrence en versionnant les clés (une version par objet qui change à chaque écriture et fait partie de la clé), ou en supprimant à nouveau après un court délai.