Initial vault setup

concepts/cache.md

@@ -0,0 +1,54 @@
+---
+title: Cache
+created: 2026-06-06
+updated: 2026-06-06
+type: concept
+tags: [tech, architecture, performance]
+confidence: high
+contested: false
+sources: [synthesized]
+---
+# ⚡ Cache
+
+## Définition Courte
+Stockage **temporaire** de données coûteuses à recalculer ou à récupérer, pour servir les requêtes suivantes **beaucoup plus vite**.
+
+## Explication Détaillée
+**Couches de cache** (de la plus proche au plus loin) :
+1. **CPU Cache** (L1, L2, L3) : nanosecondes.
+2. **RAM Cache** (Redis, Memcached) : microsecondes.
+3. **Disk Cache** (SSD) : millisecondes.
+4. **CDN Edge** (Cloudflare, Fastly) : dizaine de ms.
+5. **HTTP Cache** (browser) : réutilisé localement.
+
+**Patterns** :
+- **Cache-Aside** : l'app lit le cache, sinon lit la source et remplit.
+- **Read-Through** : le cache est transparent, lit la source si besoin.
+- **Write-Through** : l'écriture passe par le cache puis la source.
+- **Write-Behind** : écriture async (risque de perte).
+- **Cache Stampede Prevention** : éviter que 1000 requêtes régénèrent la même clé en parallèle.
+
+**Invalidation** : le plus dur en cache. TTL, événement-based, ou manuelle.
+
+## Cas d'Usage
+- Sessions utilisateurs (Redis).
+- Réponses API coûteuses (résultats LLM, RAG).
+- Assets statiques (images, JS via CDN).
+- Requêtes DB lourdes.
+- Résultats de pagination.
+
+## Outils Liés
+- **Redis**, **Memcached**, **KeyDB** (in-memory).
+- **Varnish**, **NGINX** (HTTP cache).
+- **Cloudflare**, **Fastly** (CDN).
+- **Stale-While-Revalidate** (SWR).
+
+## Pages Liées
+- [[load-balancing]]
+- [[api-gateway]]
+- [[comparatif-stockage]]
+- [[observabilite]]
+
+## Questions Ouvertes
+- Le cache L1/L2 de CPU est-il encore pertinent à optimiser en 2025 ?
+- Comment gérer le cache distribué sans point unique de défaillance ?