Cache : stratégies sans cauchemar

Prérequis : cours 4.2 (projections) ; notions HTTP (Réseaux 7.1).

Pourquoi

Le cache divise les temps par 10-100… quand il est juste. Quand il est faux, il sert du périmé avec aplomb. La stratégie, c'est : quoi cacher, combien de temps, et comment invalider.

Concepts

• Cache-aside (le classique) : lire le cache, si absent lire la source + remplir. Simple, le plus courant. Risque : thundering herd (1000 requêtes remplissent en même temps au premier miss).
• TTL : durée de vie. Court (secondes/minutes) = frais mais peu efficace ; long = efficace mais périmé. Pas de TTL magique : par donnée (prix ? secondes. catalogue ? heures).
• Invalidation : par écriture (on supprime à la modif — course possible), par événement (l'écriture publie, le cache s'aligne — propre, cf. 4.3), par version/clé (user:123:v7 — jamais de suppression, on change de clé).
• Stampede : verrou de remplissage (un seul reconstruit, les autres attendent l'ancien) ou stale-while-revalidate (servir le périmé pendant le refresh).

Exemple : la recette sûre

GET user:123 → hit ? servir : lock → source → SETEX 300 → servir
Écriture → PUBLISH user.updated:123 → invalider (ou nouvelle version de clé)

Cas réel

« Les prix ne se mettent pas à jour » : TTL de 24 h sur les prix + invalidation oubliée sur la promo. Clients facturés à l'ancien prix pendant un jour. Depuis : TTL par nature de donnée + invalidation par événement testée.

Pièges

• Cacher sans TTL (« pour aller vite ») : périmé pour toujours jusqu'au restart.
• Clés sans namespace (user:123 partagé entre apps) : collisions inter-apps.
• Cache devant une donnée critique (stock, solde) sans garde : survente. Le critique se relit à la source au moment qui compte (paiement).

À retenir

Aside + TTL par donnée + invalidation par événement ; stampede paré ; critique relu à la source.