Comment cacher pour réduire la charge DB à des millions de req/min ?

Question

IT Interview Practice · Accepted Answer

Placez une couche **cache-aside** (Redis/Memcached) devant la DB pour que les lectures touchent la mémoire, donnez aux entrées un **TTL** et **invalidez à l'écriture**, ajoutez une **protection contre le stampede** pour qu'une clé froide ne déchaîne pas un thundering herd sur la DB, et répartissez les **clés chaudes** sur des réplicas pour qu'une clé populaire ne fasse pas fondre un seul nœud.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

En **cache-aside**, l'application vérifie le cache ; sur un miss elle lit la DB et peuple le cache elle-même. En **read-through**, la bibliothèque de cache le fait pour vous. Dans les deux cas le but est le même : transformer une requête DB de 5ms en un lookup mémoire de 0,2ms, pour qu'un cache avec 95% de hit rate réduise le trafic de lecture DB **20×**. À des millions de req/min, la DB ne peut tout simplement pas servir chaque lecture — le cache est ce qui rend les chiffres possibles.

## TTL + invalidation

Deux façons de garder le cache frais, et vous avez généralement besoin des deux. Le **TTL** borne la péremption — une entrée expire après N secondes pour que les données erronées se corrigent d'elles-mêmes. L'**invalidation explicite** supprime/met à jour la clé à l'écriture pour une exactitude qui ne peut pas attendre le TTL. Le bug classique est de cacher sans invalidation et de servir des données périmées pendant des minutes ; le plus subtil est d'invalider *et* de set dans la même écriture, ce qui crée une race.

## Protection contre le stampede & clés chaudes

- **Stampede (thundering herd) :** quand une clé chaude expire, des milliers de misses concurrents frappent tous la DB en même temps et peuvent la faire tomber. Corrigez avec un **verrou par clé/single-flight** (une seule requête recalcule, les autres attendent) ou un **refresh anticipé/probabiliste** avant l'expiration.
- **Clés chaudes :** une clé (le profil d'une célébrité) peut saturer le CPU/réseau d'un seul nœud Redis. Répartissez-la — répliquez la clé sur plusieurs nœuds, ou ajoutez un petit cache local in-process devant Redis pour les items les plus chauds.

## Perspective d'entretien

L'examinateur veut vous voir réfléchir au-delà de « ajouter Redis ». Bien : cache-aside avec TTL. Excellent : vous nommez la **protection contre le stampede, la stratégie d'invalidation, la gestion des clés chaudes, et ce qui se passe lors d'une panne de cache**. Le piège est de supposer que le cache est toujours up — si Redis meurt et que chaque miss retombe sur la DB, vous obtenez une **cache-avalanche** qui fait tomber la DB aussi.

## Compromis et pannes

- **Péremption vs charge :** un TTL court = frais mais plus de misses ; un TTL long = moins de misses mais plus périmé. Ajustez par donnée.
- **Cache avalanche :** de nombreuses clés expirant ensemble (même TTL) causent un pic de charge — **jitterez** les TTL.
- **Cohérence :** le cache et la DB peuvent diverger ; pour les lectures critiques en argent, lisez la DB ou utilisez le write-through.
- **Éviction mémoire :** sous pression Redis évince selon une politique (LRU/LFU) ; une mauvaise politique abandonne silencieusement votre hot set.

Cache-aside vs read-through

TTL + invalidation

Protection contre le stampede & clés chaudes

Perspective d'entretien

Compromis et pannes

Questions connexes