Caching, ou la vitesse qu'on paie en fraîcheurCaching, or the speed you pay for in freshness

Le cache va plus vite. Mais il peut mentir — et savoir quand, c'est tout le sujet.The cache is faster. But it can lie — and knowing when is the whole subject.

Voici le dernier volume, celui de la scalabilité — et il s'ouvre par le pattern le plus rentable de tous, et le plus piégeux. Une requête est lente et appelée sans cesse ? Le réflexe est immédiat : « mets un cache ». Garder le résultat sous la main au lieu de le recalculer divise les temps de réponse par dix ou cent, et soulage la source d'autant. Le gain est si évident qu'on en oublie la contrepartie : dès qu'on copie une donnée, on a deux exemplaires de la vérité — et les garder d'accord est l'un des deux problèmes vraiment durs de l'informatique. Sans stratégie d'invalidation, le cache continue de servir l'ancienne valeur longtemps après que la source a changé : il ment. Le réflexe complet n'est donc pas « mets un cache », c'est « mets un cache, et décide d'avance comment et quand tu le rafraîchis » — et, parce que c'est le volume de la scalabilité, on ne le pose qu'avec un chiffre : un point chaud mesuré, pas une intuition.Here's the final volume, the one on scalability — and it opens with the most profitable pattern of all, and the most treacherous. A query is slow and called constantly? The reflex is immediate: 'add a cache'. Keeping the result on hand instead of recomputing it divides response times by ten or a hundred, and relieves the source by as much. The gain is so obvious you forget its counterpart: the moment you copy a piece of data, you have two copies of the truth — and keeping them in agreement is one of the two genuinely hard problems in computing. Without an invalidation strategy, the cache keeps serving the old value long after the source has changed: it lies. So the full reflex isn't 'add a cache', it's 'add a cache, and decide up front how and when you refresh it' — and, because this is the scalability volume, you only add it with a number: a measured hot path, not a hunch.

# une requête lente, appelée souvent. le réflexe : « mets un cache ». la moitié du geste seulement.
cache = {}
def get_profile(user_id):
    if user_id in cache:
        return cache[user_id]              # ✓ rapide : on évite la base
    row = db.query("SELECT * FROM profiles WHERE id = ?", user_id)   # 💥 lent, mais TOUJOURS vrai
    cache[user_id] = row
    return row

def update_profile(user_id, data):
    db.update("profiles", user_id, data)   # 💥 on écrit la source… et on oublie le cache.
    # → le cache garde l'ancienne valeur. tous les lecteurs voient le PASSÉ, peut-être pour des heures.
# un cache sans stratégie d'invalidation n'est pas un cache : c'est un mensonge qui s'installe.

Le cache ment, la vérité se dédouble, et le jour où il tombe, la base tombe avec.The cache lies, the truth doubles, and the day it falls, the database falls with it.

Un cache mal conçu a trois coûts, et aucun n'est visible le jour où on le pose — tous arrivent plus tard. D'abord il ment : sans invalidation reliée aux écritures, il sert l'ancienne valeur longtemps après que la source a changé, et plus le TTL est long, plus le mensonge dure. Ensuite la vérité se dédouble : on a désormais deux copies à garder d'accord, et entre les deux s'ouvrent des courses — deux écritures qui s'entrelacent, mille lecteurs qui ratent en même temps à l'expiration et foncent tous sur la base d'un coup. Enfin les modes de panne se déplacent : le cache, en absorbant l'essentiel du trafic, est devenu porteur — et le jour où il tombe ou démarre froid, toute la charge qu'il masquait s'abat d'un seul coup sur une base qui ne l'a jamais vue. Trois douleurs différées, qu'on paie d'autant plus cher qu'on les a ignorées au départ.A badly designed cache has three costs, and none shows the day you add it — all arrive later. First it lies: without invalidation tied to writes, it serves the old value long after the source changed, and the longer the TTL, the longer the lie. Then the truth doubles: you now have two copies to keep in agreement, and between them races open — two writes interleaving, a thousand readers missing at once on expiry and all rushing the database together. Finally the failure modes shift: the cache, by absorbing most of the traffic, has become load-bearing — and the day it falls or starts cold, all the load it masked crashes at once onto a database that never saw it. Three deferred pains, paid all the more dearly for having been ignored at the start.

# 14h00 : on écrit le nouveau prix en base. le cache garde l'ancien (TTL = 1h).
db.update("products", id, {"price": 89})       # 💥 source à jour, cache périmé pendant 1h
# 14h00–15h00 : tous les clients voient 99 €, sont facturés 89 €. (le cache ment)

# 15h00 : l'entrée expire. 3 000 requêtes/s la ratent AU MÊME instant…
price = cache.get(id) or db.query(...)          # 💥 …et foncent toutes sur la base (stampede)

# 15h02 : le serveur de cache redémarre, vide. 100 % du trafic bascule sur la base.
# la base, habituée à 5 % des lectures, reçoit 100 % d'un coup → elle tombe. (panne déplacée)

Miss, hit, mensonge, invalidation — la boucle qui garde le cache honnête.Miss, hit, lie, invalidation — the loop that keeps the cache honest.

Le cache ne se comprend pas comme un interrupteur, mais comme un cycle de vie. L'animation suit une seule entrée — un prix — à travers ses cinq moments : le miss qui la remplit depuis la base, le hit qui la sert en un éclair, l'instant où la source change et où le cache se met à mentir, l'invalidation qui supprime l'entrée périmée, et le miss suivant qui la recharge à jour. Surveille les deux valeurs — celle du cache, celle de la base — et l'étiquette « vrai / ment / vide » : c'est leur écart qui raconte pourquoi l'invalidation n'est pas une option mais le pivot de tout le pattern.The cache isn't understood as a switch, but as a life cycle. The animation follows a single entry — a price — through its five moments: the miss that fills it from the database, the hit that serves it in a flash, the instant the source changes and the cache starts lying, the invalidation that removes the stale entry, and the next miss that reloads it fresh. Watch the two values — the cache's, the database's — and the 'true / lying / empty' label: it's their gap that tells why invalidation isn't an option but the pivot of the whole pattern.

def get_price(id):
    if (v := cache.get(id)) is not None:
        return v                              # HIT — 2 ms, on ne touche pas la base
    v = db.query("SELECT price FROM products WHERE id = ?", id)   # MISS — 120 ms
    cache.set(id, v, ttl=300)                 # on remplit, TTL = filet de sécurité (5 min)
    return v

def set_price(id, price):
    db.update("products", id, {"price": price})   # 1) on écrit la SOURCE d'abord
    cache.delete(id)                              # 2) puis on INVALIDE — le prochain read rechargera
    # ordre crucial : source puis cache. l'inverse laisse une fenêtre où le cache est "à jour" et faux.
    # reste une course rare : un get_price qui a lu l'ancien prix AVANT l'update peut le
    # ré-écrire APRÈS le delete. c'est elle que le TTL borne — d'où « ceinture et bretelles ».

Cacher sans mesurer, ou cacher sans jamais invalider.Caching without measuring, or caching without ever invalidating.

Deux dérives, qui vont souvent de pair parce qu'elles naissent du même réflexe — « ça ne peut pas faire de mal de cacher ». La première cache sans chiffre : on pose un cache sur des données froides, peu relues, dont chaque requête est quasi unique. Le taux de hits frôle zéro, et le cache ne rapporte rien — il ne fait qu'ajouter de la mémoire consommée, de la complexité, et un risque d'incohérence, pour un gain qui n'existe pas. La seconde cache sans invalidation : un TTL choisi au hasard tient lieu de stratégie, aucun chemin d'écriture ne supprime l'entrée, et le cache sert du périmé jusqu'à expiration. La première dérive paie un coût sans bénéfice ; la seconde transforme la vitesse en mensonge. Bascule le toggle : repère le cache qu'aucune mesure ne justifie, et celui qu'aucune écriture ne rafraîchit.Two drifts, which often go together because they spring from the same reflex — 'caching can't hurt'. The first caches without a number: you put a cache on cold data, rarely re-read, where each request is nearly unique. The hit rate grazes zero, and the cache returns nothing — it only adds consumed memory, complexity, and an inconsistency risk, for a gain that doesn't exist. The second caches without invalidation: a randomly chosen TTL stands in for a strategy, no write path removes the entry, and the cache serves stale until expiry. The first drift pays a cost with no benefit; the second turns speed into a lie. Flip the toggle: spot the cache no measurement justifies, and the one no write refreshes.

# on a MESURÉ : /price est lu 3000×/s, écrit 5×/jour, et coûte 120 ms. ratio lecture/écriture énorme.
# → point chaud réel : le cache est justifié. on le conçoit complet.
def get_price(id):
    if (v := cache.get(id)) is not None:
        return v                                  # hit
    with single_flight(id):                       # ✓ anti-stampede : un seul recalcul à la fois
        if (v := cache.get(id)) is not None: return v   # re-check : un autre vient de remplir
        v = db.query("SELECT price FROM products WHERE id = ?", id)
        cache.set(id, v, ttl=300)                 # ✓ TTL court = filet contre l'invalidation oubliée
        return v

def set_price(id, price):
    db.update("products", id, {"price": price})   # ✓ source d'abord
    cache.delete(id)                              # ✓ invalidation explicite à CHAQUE écriture
# et si le cache tombe : get_price retombe sur la base. dégradé, lent — mais vrai et debout.

Lire vite, ou lire vrai — et le cache bien réglé fait les deux.Read fast, or read true — and a well-tuned cache does both.

Quand ne pas (encore) cacherWhen not to cache (yet)

Le cache a un loyer permanent : une seconde copie à invalider, un mode de panne en plus, une incohérence possible. On lit directement la source — et c'est correct — quand :The cache has permanent rent: a second copy to invalidate, an extra failure mode, a possible inconsistency. You read straight from the source — and that's fine — when:

• aucun goulot n'est mesuré : la requête est déjà rapide, ou rarement appelée. Cacher « au cas où » optimise une intuition — c'est précisément l'erreur que ce volume refuse (la règle : on n'entre dans la scalabilité qu'avec un chiffre).no bottleneck is measured: the query is already fast, or rarely called. Caching 'just in case' optimizes a hunch — precisely the error this volume refuses (the rule: you enter scalability only with a number).
• la donnée est écrite autant qu'elle est lue, ou peu réutilisée : un faible ratio lecture/écriture, ou des clés quasi uniques, donnent un taux de hits si bas que le cache coûte plus qu'il n'épargne. Pas de point chaud, pas de cache.the data is written as much as it's read, or little reused: a low read/write ratio, or near-unique keys, give a hit rate so low the cache costs more than it saves. No hot path, no cache.
• la moindre péremption est inacceptable : un solde débiteur, un droit d'accès qu'on vient de révoquer, un stock au dernier exemplaire. Là où servir le passé une seule seconde est une faute, on lit la source — ou l'on accepte la complexité d'un cache à invalidation forte et à TTL nul, ce qui revient souvent à ne pas cacher.the slightest staleness is unacceptable: an overdrawn balance, an access right just revoked, a last-item stock. Where serving the past for even a second is a fault, you read the source — or you accept the complexity of a strongly-invalidated, zero-TTL cache, which often amounts to not caching.

Le réflexe n'est donc pas « ajoute un cache, c'est plus rapide » : c'est « ai-je mesuré un point chaud lu bien plus qu'écrit, et sais-je dire quand le cache ment et ce qui le rafraîchit ? Alors cache, avec invalidation et TTL. Sinon, lis la source — elle est lente, mais elle ne ment jamais. »So the reflex isn't 'add a cache, it's faster': it's 'have I measured a hot path read far more than written, and can I say when the cache lies and what refreshes it? Then cache, with invalidation and TTL. Otherwise, read the source — it's slow, but it never lies.'

Mot de l'éditeurFrom the editor

Le Vol 8 s'ouvre, et c'est le dernier — celui de la scalabilité, placé tout à la fin pour une raison de principe. C'est le terrain le plus exposé à l'optimisation prématurée, et le cache en est l'emblème : si rentable, si facile à poser, qu'on le dégaine par réflexe sur des requêtes dont on n'a jamais mesuré le coût. D'où la règle qui gouverne tout le volume — on n'y entre qu'avec un chiffre. Le cache illustre aussi la vérité que la série n'a cessé de marteler : il n'existe pas de geste gratuit. Copier une donnée pour la lire vite, c'est accepter une seconde source de vérité, donc l'invalidation — « l'une des deux choses vraiment dures de l'informatique ». Le débutant voit un bouton « plus rapide » ; l'architecte voit un arbitrage entre la vitesse et la fraîcheur, et le règle consciemment, sur une tolérance au mensonge qu'il a choisie.Vol 8 opens, and it's the last — the one on scalability, placed at the very end on principle. It's the ground most exposed to premature optimization, and the cache is its emblem: so profitable, so easy to add, that you draw it by reflex on queries whose cost you never measured. Hence the rule that governs the whole volume — you enter only with a number. The cache also illustrates the truth the series has hammered throughout: there's no free gesture. Copying data to read it fast means accepting a second source of truth, hence invalidation — 'one of the two genuinely hard things in computing'. The beginner sees a 'faster' button; the architect sees a trade-off between speed and freshness, and tunes it consciously, on a tolerance for lying they chose.

Le cache résout un problème de vitesse de lecture en gardant une seule source de vérité, simplement recopiée. Mais que faire quand la source elle-même ne tient plus sur une seule machine — quand la donnée est trop grosse, ou les écritures trop nombreuses pour un seul nœud ? C'est le sujet du #2, le sharding : découper la donnée en morceaux répartis sur plusieurs machines, et payer le prix des requêtes qui doivent les traverser. Et derrière le cache comme derrière le sharding rôde la même question, qu'on a frôlée ici avec le couple vitesse/fraîcheur et au Vol 7 avec la cohérence à terme : dès qu'une donnée existe en plusieurs exemplaires, peut-on être à la fois cohérent et disponible quand le réseau se coupe ? Le #3 y répondra par le théorème CAP — le mur contre lequel toute la scalabilité distribuée vient buter, et la note finale de la série.The cache solves a read-speed problem while keeping a single source of truth, merely copied. But what to do when the source itself no longer fits on one machine — when the data is too big, or the writes too many for a single node? That's #2's subject, sharding: splitting the data into pieces spread across several machines, and paying the price of queries that must cross them. And behind the cache as behind sharding lurks the same question, brushed here with the speed/freshness pair and in Vol 7 with eventual consistency: once data exists in several copies, can you be both consistent and available when the network cuts? Issue #3 will answer with the CAP theorem — the wall every distributed scalability scheme hits, and the series' final note.

Les voisins que ce numéro débloqueThe neighbors this issue unlocks

• Cache-aside — le motif de lecture par défaut, celui de tout ce numéro : l'application interroge le cache, sert sur hit, et sur miss lit la source puis remplit. Le cache reste « à côté » du chemin de données, jamais sur le chemin critique d'écriture — d'où sa principale vertu : s'il tombe, on lit simplement la source. Sa contrepartie : c'est à l'application de gérer l'invalidation, donc de ne jamais oublier un chemin d'écriture.the default read pattern, the one this whole issue uses: the app queries the cache, serves on hit, and on miss reads the source then fills. The cache stays 'beside' the data path, never on the critical write path — hence its main virtue: if it falls, you simply read the source. Its counterpart: it's up to the app to handle invalidation, so to never forget a write path.
• Write-through — la stratégie d'écriture inverse : chaque écriture passe par le cache, qui écrit ensuite la source dans le même geste. Le cache n'est jamais périmé puisqu'il est mis à jour avant la lecture — au prix d'écritures plus lentes, et d'un cache désormais sur le chemin critique. Avec son cousin write-behind (écrire le cache tout de suite, la source plus tard, en risquant la perte), il forme la palette des stratégies entre lesquelles la fraîcheur exigée fait choisir.the inverse write strategy: every write goes through the cache, which then writes the source in the same gesture. The cache is never stale since it's updated before the read — at the cost of slower writes, and a cache now on the critical path. With its cousin write-behind (write the cache at once, the source later, risking loss), it forms the palette of strategies between which required freshness makes you choose.
• CDN & TTL — le cache poussé jusqu'au bord du réseau. Un CDN réplique les contenus (images, pages, réponses d'API) sur des serveurs proches de l'utilisateur, transformant un cache applicatif en cache géographique — et y ramenant exactement les mêmes questions : que met-on en cache, et avec quel TTL ? Le TTL, justement, est le réglage universel de tout cache : la durée de vie d'une entrée, donc la durée maximale du mensonge qu'on accepte. Le choisir, partout, c'est choisir où l'on place le curseur entre vitesse et fraîcheur.the cache pushed to the network's edge. A CDN replicates content (images, pages, API responses) on servers near the user, turning an application cache into a geographic one — and bringing back exactly the same questions: what do you cache, and with what TTL? The TTL, precisely, is every cache's universal knob: an entry's lifetime, hence the maximum duration of the lie you accept. Choosing it, everywhere, is choosing where you set the cursor between speed and freshness.

Le kata — écris-le, ne le relis pasThe kata — write it, don't reread it

# test_lru_ttl.py — la spec EST le harnais : fais-le passer au vert.
# un cache borné : capacité fixe, on évince le moins récemment UTILISÉ, et le périmé est un miss.

def test_hit_puis_miss():
    c = LRU(capacity=2, ttl=300)
    c.set("a", 1)
    assert c.get("a") == 1                        # posé puis lu → hit
    assert c.get("z") is None                     # jamais vu → miss

def test_evince_au_dela_de_la_capacite():
    c = LRU(capacity=2, ttl=300)
    c.set("a", 1); c.set("b", 2); c.set("c", 3)   # capacité 2 → une entrée doit partir
    assert c.get("a") is None                      # "a", le plus ancien, a été évincé
    assert c.get("b") == 2 and c.get("c") == 3

def test_le_ttl_perime_une_entree():
    c = LRU(capacity=2, ttl=300)
    c.set("a", 1)
    avance_le_temps(301)                           # au-delà du TTL…
    assert c.get("a") is None                      # …présente mais périmée = miss

def test_reecrire_met_a_jour_la_valeur():
    c = LRU(capacity=2, ttl=300)
    c.set("a", 1); c.set("a", 9)
    assert c.get("a") == 9                         # même clé ré-écrite → dernière valeur

def test_lire_protege_de_l_eviction():
    c = LRU(capacity=2, ttl=300)
    c.set("a", 1); c.set("b", 2)
    c.get("a")                                     # on TOUCHE "a" : il redevient le plus récent
    c.set("c", 3)                                  # une entrée doit partir…
    assert c.get("a") == 1                         # …c'est "b", pas "a"
    assert c.get("b") is None                      # LRU = moins récemment UTILISÉ, pas le plus ancien posé