💻 Développement

caching-strategy

Stratégie de cache adaptée à chaque cas d'usage (Redis, Memcached, in-memory).

⚡ Installation & lancement en 1 commande

Copiez-collez dans votre terminal : le skill s'installe dans ~/.claude/skills et Claude Code se lance directement dessus.

macOS / Linux
curl -fsSL https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.sh | sh -s -- caching-strategy --launch
Windows (PowerShell)
iex "& { $(iwr -useb https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.ps1) } caching-strategy -Launch"

🚀 Déjà installé ?

claude "/caching-strategy"

Ou tapez /caching-strategy dans une session Claude Code, ou décrivez simplement votre besoin — le skill se déclenche automatiquement via le skill-router.

🔑 Déclencheurs automatiques

Le skill s'active automatiquement quand votre demande contient :

cacheRediscachingmise en cacheperformancecache invalidationCDNdistributed cache

📦 Installation manuelle

git clone https://github.com/khalilbenaz/claude-skills-collection.git cp -r claude-skills-collection/dev-skills/caching-strategy ~/.claude/skills/

Source : dev-skills/caching-strategy

📖 Manuel

Caching Strategy

Workflow

  1. Identifier les données à cacher : Cibler les hot data (accédées très fréquemment), les données read-heavy (ratio lecture >> écriture), et les résultats de calculs coûteux (agrégations, appels API tiers, requêtes DB complexes) ; éviter de cacher les données qui changent trop souvent ou qui nécessitent une cohérence stricte.
  2. Choix du type de cache : In-process/in-memory (MemoryCache, dictionnaire) pour la latence minimale sur instance unique ; distributed cache (Redis, Memcached) pour le partage multi-instance et la persistance optionnelle ; CDN (Cloudflare, Azure CDN) pour les assets statiques et réponses HTTP ; database query cache pour les requêtes répétitives ; browser cache (Cache-Control, ETag) pour réduire les allers-retours.
  3. Pattern de caching : Cache-aside (lazy loading, l'application gère le cache manuellement) pour le contrôle maximal ; read-through (le cache charge depuis la DB automatiquement) pour simplifier le code applicatif ; write-through (écriture synchrone en DB et cache) pour la cohérence forte ; write-behind/write-back (écriture asynchrone en DB) pour la performance maximale en écriture.
  4. Politique d'expiration : Définir un TTL adapté au taux de changement des données (court pour les données volatiles, long pour les données stables) ; utiliser LRU (Least Recently Used) pour l'éviction mémoire par défaut ; LFU (Least Frequently Used) pour les données avec popularité stable ; envisager l'invalidation event-based (purge ciblée sur événement métier) pour les données critiques.
  5. Cache key design : Adopter une convention claire ({service}:{entity}:{id}, ex. users:profile:42) ; versionner les keys si le format des données change (v2:users:profile:42) ; utiliser le namespacing pour faciliter l'invalidation groupée (SCAN users:*) ; éviter les keys trop longues ou contenant des données sensibles.
  6. Gestion de la cohérence : Définir la stratégie d'invalidation (TTL passif, invalidation active sur mutation, cache-busting) ; prévenir le cache stampede (thundering herd) avec le mutex/lock sur le premier chargement ou le probabilistic early expiration ; gérer le stale-while-revalidate pour servir du cache périmé pendant le rechargement en arrière-plan.
  7. Implémentation : Redis (structures de données riches : strings, hashes, sets, sorted sets, streams) pour les cas d'usage avancés ; IDistributedCache (.NET) ou Spring Cache (Java) pour l'abstraction framework ; output caching pour les réponses HTTP complètes ; function memoization pour les calculs purs.
  8. Monitoring : Surveiller le hit rate (objectif > 80-90% selon le cas), le miss rate, l'éviction rate (signal de mémoire insuffisante), l'utilisation mémoire et la latence ; configurer des alertes sur la dégradation du hit rate ; analyser les patterns d'accès pour affiner les TTL et la politique d'éviction.

Règles