Quelles stratégies de cache améliorent la performance d'une API Node ?

Question

IT Interview Practice · Accepted Answer

**Le caching** stocke les résultats d'opérations coûteuses (requêtes DB, calculs, appels API externes) afin que les requêtes répétées puissent être servies rapidement sans refaire le travail. C'est l'une des optimisations de performance ayant le plus d'impact pour une API.

## Caching en mémoire (plus rapide, instance unique)

```js
const cache = new Map();

async function getUser(id) {
  if (cache.has(id)) return cache.get(id); // cache HIT — instant
  const user = await db.findUser(id);       // cache MISS — do the work
  cache.set(id, user);
  return user;
}
```

Simple et extrêmement rapide, mais le cache est **par processus** (non partagé entre instances) et perdu au redémarrage. Bon pour les petites données chaudes — mais nécessite une éviction (utiliser un cache LRU comme `lru-cache`) pour limiter la mémoire.

## Caching distribué avec Redis (partagé, scalable)

```js
import { createClient } from "redis";
const redis = createClient();

async function getUser(id) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);          // hit

const user = await db.findUser(id);
  await redis.setEx(`user:${id}`, 3600, JSON.stringify(user)); // cache for 1h (TTL)
  return user;
}
```

**Redis** est le standard pour le caching à travers plusieurs instances serveur — un stockage partagé et rapide qui survit aux redémarrages et s'adapte à votre application. Le **TTL** (time-to-live) expire automatiquement les entrées afin que les données ne restent pas obsolètes indéfiniment.

## Caching HTTP (laisser les clients/CDN cacher)

```js
res.set("Cache-Control", "public, max-age=3600"); // browsers/CDN cache for 1h
res.set("ETag", hash);                            // conditional requests (304 Not Modified)
```

Les en-têtes de cache HTTP externalisent le caching aux navigateurs et CDN entièrement — le cache le plus rapide est la requête qui n'atteint jamais votre serveur.

## La partie difficile : l'invalidation du cache

```js
// when data changes, the cache must be updated or cleared, or users see stale data
async function updateUser(id, data) {
  await db.updateUser(id, data);
  await redis.del(`user:${id}`); // INVALIDATE — next read repopulates with fresh data
}
```

Le plus grand défi du caching est l'**invalidation** — s'assurer que les mises à jour effacent/actualisent les entrées de cache affectées afin que les utilisateurs ne voient pas de données obsolètes. Stratégies : TTL (accepter une brève obsolescence), write-through (mettre à jour le cache à l'écriture), ou suppression explicite lors de mutations.

## Quoi cacher (et ne pas cacher)

```text
✓ Read-heavy, infrequently-changing data (config, product catalogs, user profiles)
✓ Expensive computations, external API responses
✗ Highly dynamic/personalized or rapidly-changing data (or use very short TTLs)
✗ Sensitive data without care for who can read the cache
```

## Pourquoi c'est important

Le caching réduit dramatiquement la latence et la charge de la base de données/services externes, souvent la différence entre une API lente et une API rapide et scalable.

Connaître les couches — en mémoire (plus rapide, par instance, limité avec LRU), Redis (partagé entre instances), et caching HTTP/CDN (externaliser entièrement) — vous permet de choisir la bonne stratégie.

Et comprendre la difficulté centrale du caching, l'**invalidation** (via TTL ou effacement explicite à l'écriture), c'est ce qui prévient l'échec du compromis classique de servir aux utilisateurs des données obsolètes.

Le caching efficace est l'un des outils les plus impactants pour la performance et la scalabilité des API.

Caching en mémoire (plus rapide, instance unique)

Caching distribué avec Redis (partagé, scalable)

Caching HTTP (laisser les clients/CDN cacher)

La partie difficile : l'invalidation du cache

Quoi cacher (et ne pas cacher)

Pourquoi c'est important

Questions connexes