Un cache bien dimensionné divise la latence et la charge sur les bases — jusqu’au jour où les utilisateurs voient des données périmées ou des écarts entre écrans. Le problème n’est presque jamais le stockage : c’est quand et comment vous invalidez les clés quand la source de vérité change.
TTL seul : simple et imprécis
Le time-to-live est facile à opérer : aucun couplage avec le métier. Mais choisir une durée « ni trop courte ni trop longue » est un compromis permanent : soit vous rafraîchissez trop tard (expérience médiocre), soit vous sur-requêtez l’origine. Le TTL convient aux données dont la fraîcheur est tolérée explicitement (catalogues, références).
Invalidation par événement
Quand une écriture métier confirme un changement (commande validée, stock mis à jour), publiez un événement ou appelez un service d’invalidation qui purge les clés concernées — souvent un préfixe ou un tag de cache. Le défi est la liste des clés impactées : documentez les chemins de lecture pour éviter les angles morts.
Cache-aside vs read-through vs write-through
En cache-aside, l’app lit le cache puis la base ; l’invalidation est à votre charge. En write-through, l’écriture met à jour cache et base ensemble — plus cohérent, plus couplé. Il n’y a pas de réponse universelle : choisissez selon la criticité de la fraîcheur et la complexité opérationnelle.
Cohérence et expérience utilisateur
Exposez parfois un indicateur de fraîcheur (« mis à jour il y a X minutes ») pour les tableaux de bord non temps réel — cela cadre l’attente. Pour les flux financiers ou réglementaires, préférez pas de cache sur le chemin critique ou une invalidation synchrone mesurée.
CDN, reverse proxy et cache HTTP
Au-delà du cache applicatif, les CDN et reverse proxies (Varnish, NGINX, CloudFront, Fastly) mettent en cache des réponses GET avec clés dérivées de l’URL, headers Vary, et cookies. Une purge partielle ratée laisse des fragments périmés visibles selon géolocalisation. Documentez quels chemins doivent être purgeables par tag ou préfixe, et testez après déploiement front que les assets versionnés évitent purge globale.
Stampede, thundering herd et verrous
Lorsqu’un TTL expire pour tous les clients en même temps, la charge retombe brutalement sur l’origine (cache stampede). Des verrous sur clé (singleflight), jitter aléatoire sur TTL, et pré-chargement asynchrone réduisent le phénomène. Surveillez latence p95/p99 post invalidation massive.
Observabilité : hit ratio, âge, invalidations ratées
Métriquez taux de hit, âge moyen des objets, nombre d’invalidations par seconde, et erreurs de purge. Alertez quand le hit ratio chute après un déploiement — signe souvent d’URLs mal cléifiées ou de Vary incorrect.
Tests de charge et régression
Les tests de charge doivent inclure scénarios post invalidation (cold cache)** et mélange lecture/écriture. Un système rapide en steady state mais fragile au vidage partiel échouera en production.
Antipatterns : double écriture sans stratégie
Écrire directement dans deux caches sans transaction distribuée crée des races : préférez une source de vérité et invalidation déterministe ou idempotente.
GraphQL, BFF et granularité des clés
Les API GraphQL et couches BFF agrègent plusieurs sources : une invalidation trop grossière vide trop de clés, une trop fine oublie des dérivés. Modélisez des tags métier (produit, compte, segment) plutôt que des URLs brutes lorsque possible.
Edge computing et caches locaux
Les workers edge et PWA offline ajoutent des caches client : stratégies stale-while-revalidate et ETags réduisent bande passante mais compliquent cohérence multi-appareil. Documentez comportement attendu lorsque données changent côté serveur.
Cas d’usage e-commerce et inventaire
Stock faible latence mérite invalidation stricte ou verrou optimiste côté commande ; catalogue peut tolérer quelques secondes de décalage si prix affiché est verrouillé au panier.
Redis, clustering et hot keys
Avec Redis cluster ou réplication, les hot keys concentrent la charge sur un nœud ; sharding fonctionnel ou réplication lecture peuvent aider, mais compliquent invalidation globale. Évitez FLUSHALL en production : préférez tags ciblés.
FAQ — invalidation
Peut-on s’appuyer uniquement sur TTL pour paiement ? Non recommandé : couplez événements métier ou pas de cache sur chemin sensible.
Comment tester ? Chaos engineering léger : expirez TTL artificiellement sur pré-prod et mesurez récupération.
Multi-région et délais de propagation
Lorsque répliques lecture traînent, l’invalidation rapide côté écriture peut laisser lecteurs distant voir anciennes valeurs quelques centaines de ms. Choisissez read-your-writes là où nécessaire ou délais produit acceptables.
Coût et taille mémoire
Sur-dimensionner TTL pour économiser CPU augmente RAM et risque staleness. Optimisez taille valeurs (compression, champs nécessaires) pour réduire pression mémoire et réseau.
En synthèse
Une stratégie d’invalidation durable combine TTL là où la tolérance existe, événements là où le métier exige la cohérence, et clarté produit sur ce qui est éventuellement périmé.
Vous optimisez la performance ou la résilience applicative ? Découvrez les services ou écrivez via le formulaire de contact.