Cache-aside

L'application lit d'abord le cache et, en cas de miss, lit la base puis remplit le cache. C'est le patron le plus courant : le cache ne contient que ce qui est demandé, et sa panne dégrade en lectures plus lentes plutôt qu'en erreurs.

Où on le retrouve dans les vrais systèmes

  • Cache en mémoire

    Le taux de hit dépend de la part du working set qui tient en mémoire, du TTL et de la politique d'éviction. Si le cache tombe ou est vidé, toutes les lectures tombent d'un coup sur la base : prévois cette ruée. Le write-behind est rapide mais perd des écritures si un nœud meurt sans réplica.

    En production : Redis (Amazon ElastiCache, Azure Cache), Valkey, Memcached, Dragonfly

Regarde-le casser, puis répare-le

Construis une architecture, envoie-lui une journée de trafic et de pannes, et comprends pourquoi elle tient ou cède. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable