In a meta-framework's server render, how does a per-render deduplication cache differ in lifetime and scope from a store that outlives the request?

## Two caches that are easy to confuse Both of these sit on the server, both stop a read from happening twice, and both are described as "caching". They differ on the only two properties that matter: **how long the copy lives** and **who can be served it**. | | Per-render dedupe | Store that outlives the request | | --- | --- | --- | | Created | when a request starts rendering | once, and kept | | Discarded | when that response is finished | on expiry, eviction, removal, or restart | | Scope | one request | every request that computes a matching key | | Saves work | within one render | across requests and visitors | | Personalised reads | safe by construction | only if identity is in the key | ## What per-render dedupe actually does A render tree normally reads the same thing more than once: a layout needs the current account, a nested part of the page needs it again, a third part needs it to decide what to show. Without dedupe, that is three reads of the same value for one response. With dedupe: 1. The framework creates a per-request context when the request arrives, including an empty map of in-flight and completed reads. 2. The first caller misses, starts the read, and stores the pending result under a key derived from the call and its arguments. 3. Later callers within that same render find the entry and receive the same result, rather than issuing a second read. 4. When the response is finished, the request context - map included - is dropped. Two properties follow. First, correctness: every part of one render sees a **consistent** value, instead of two reads that raced and disagreed. Second, safety: the map cannot outlive the response, so a personalised value in it cannot reach another visitor. ## What it does not do - It does **not** reduce load across requests. Each concurrent render gets its own map, so a hundred simultaneous requests perform a hundred reads. - It does **not** survive anything - not a restart, not the next request from the same browser a second later. - It does **not** make a read safe to place elsewhere. Deduping a personalised read says nothing about whether its result may go into a longer-lived copy. ## The store that outlives the request This is the placement people usually mean by "caching": a read's result is kept so that later requests can be answered without doing the work again. The load reduction is real and can be large. The cost is that the copy is now addressable by a key rather than by a person, so the key is doing the job that identity used to do. If the key contains only a URL or a query string, then every visitor sharing that URL shares the copy - which is exactly what you want for a public product listing and exactly what you must not have for an account summary. ## The trap: module-scope state on a long-running server The most common way teams get this wrong is not choosing the wrong cache, it is believing they chose the request-scoped one. A map or client object created at module scope - created once, the first time the module is loaded - and then used during render is **not** per render. On a long-running server process, module-level state is created once and shared by every request that process handles for its entire life, which makes it behave like an in-process shared store with none of the key discipline that store would normally get. This is also where deployment shape changes the symptom. On a long-running process, module state accumulates for days. On a platform that starts a fresh short-lived instance per burst of traffic, the same code may look correct in testing because instances are recycled often, then leak once traffic keeps an instance warm across two different visitors. "It worked locally" is not evidence here. ## Choosing between them - Use dedupe when the same value is needed by several parts of one response and consistency within that response matters. - Use a longer-lived store when the read is expensive, the result is the same for many requests, and you can state the audience of the key out loud. - Use **both** for a public read: dedupe keeps one render honest, the store keeps the origin from doing the work repeatedly. - Use neither - a plain read on every request - when the value is personalised, cheap, or changes faster than any window you would be willing to accept. Meta-frameworks differ in how explicit this is. Some provide a request-scoped dedupe automatically for reads made through their own data primitives; others provide nothing and expect you to pass the value down through the render instead. Passing it down is not a worse answer - it is the same scope with no cache at all.