Cache-aside (Lazy Loading)

DevOps 🟡 Mid

Définition

Stratégie où l'application vérifie le cache d'abord, puis lit la DB en cas de miss et remplit le cache. Le cache ne se remplit qu'à la demande.

Analogie

Tu cherches dans ton tiroir (cache), si ce n'est pas là tu vas au grenier (DB) et tu ranges une copie dans le tiroir.

Exemple de code

async function getUser(id) {
  let user = await cache.get(`user:${id}`);
  if (!user) {
    user = await db.findUser(id);
    await cache.set(`user:${id}`, user, 'EX', 300);
  }
  return user;
}

Cas d'usage

Pattern le plus courant pour accélérer les lectures fréquentes sans charger la DB.

Anti-pattern

Pas de TTL : les données en cache deviennent stales indéfiniment.

Termes liés

#devops#caching#interview

En entretien

Explique-moi le pattern cache-aside.
L'application vérifie d'abord le cache, et en cas de miss elle lit la base de données puis remplit le cache ; celui-ci ne se remplit donc qu'à la demande. C'est comme chercher dans ton tiroir (cache) et, si ce n'est pas là, aller au grenier (DB) puis ranger une copie dans le tiroir.
Pourquoi utiliser le cache-aside plutôt que d'écrire directement en base ?
C'est le pattern le plus courant pour accélérer les lectures fréquentes sans charger la base de données. Le code type interroge cache.get() d'abord, puis db.findUser() seulement si le cache ne répond rien.
Quel piège fréquent rend le cache-aside dangereux ?
L'absence de TTL : les données en cache deviennent stales indéfiniment. Dans l'exemple, le set utilise 'EX', 300 pour fixer une expiration de 300 secondes.

Fiche mise à jour le 2026-09-27