---
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 ?