In a cache of server data that components subscribe to by key, what stages does an entry pass through before it leaves memory?

## Why an entry needs a lifecycle at all A cache that only stored values would grow without limit and would never know when to check the server again. So each entry carries bookkeeping alongside the data: when the data arrived, how many components are currently subscribed to its key, and when the last of them went away. Those three facts drive every decision the cache makes. ## The stages | stage | what is true | reads served from memory? | refetches? | in memory? | |---|---|---|---|---| | **created / loading** | first request for this key is in flight, no value yet | no value to serve | the initial fetch | yes | | **fresh** | inside the staleness window | yes | no | yes | | **stale** | past the staleness window, still subscribed | yes | on a trigger | yes | | **unused** | last subscriber gone, value retained | yes, to a new subscriber | no | yes | | **collected** | retention window elapsed while unused | no, next read is a cold miss | n/a | no | The order is not strictly linear. An entry can be created and go stale before anything reads it again, or be unused and then picked up by a new subscriber, which puts it straight back into fresh or stale depending only on its arrival time. ## The two timers people conflate 1. **The staleness window** is about **trust**. It starts when the response arrives and decides whether a read also causes a refetch. It says nothing about memory. 2. **The retention window** is about **memory**. It starts when the subscriber count for the key drops to zero and decides how long an orphaned entry is kept before being dropped. They are independent, and each combination is meaningful: - short staleness, long retention — the common default. Navigating back paints instantly from the retained value, then corrects itself with one refetch. - long staleness, short retention — memory-lean but easy to get wrong: leave a screen briefly and the entry is gone, so the return trip is a cold load even though the value would still have been trusted. - zero staleness, long retention — every visit shows the retained value and then refetches. Correct, chatty, and the usual answer for data that changes often. - zero retention — the cache stops being a cache across navigation; it only deduplicates the readers alive at the same instant. ## Unused is not the same as invalid The most useful idea in this list is **unused**, sometimes reasoned about as an inactive entry. Nothing is wrong with the data; it simply has no reader. Keeping it is what makes back-navigation feel instant, and it is also why an entry can be refetched the moment a component mounts again rather than on a timer while nobody was looking. Two consequences follow: - **Nothing refetches an unused entry on its own.** Interval, focus and reconnect refetching are driven by subscribers; with no subscriber there is nobody to render a result, so polling an unused key spends requests on nothing. An explicit mark, or a value written into the cache by something else, can still touch the entry — what does not happen is a scheduled request on its behalf. - **An unused entry can be arbitrarily old when it is picked up.** It is served anyway, then revalidated, which is exactly the stale-while-revalidate read. This is why a return visit shows old content for a moment — that is the design working, not a bug. ## What resets what - A landed response resets the arrival time, making the entry fresh again. - A new subscriber cancels the pending collection for that key. - An explicit invalidation marks the entry stale immediately; whether it refetches now depends on whether anyone is subscribed. Invalidating a key nobody reads should mark it, not fetch it. - Dropping an entry outright is different from invalidating it: invalidation keeps the value for stale-while-revalidate reads, while dropping it forces the next reader into a loading state. Prefer invalidation unless the stored value is genuinely unsafe to show. ## Operating it When an app feels chatty, look at the staleness window and the refetch triggers. When an app feels slow on every navigation despite a cache, look at the retention window and at key stability — a key that is not built deterministically from the request never matches an existing entry, so entries accumulate as one-shot misses and the cache appears to do nothing while consuming memory. When memory grows in a long session, look for unbounded key families: one entry per keystroke of a search box, or per scroll position, each retained for the full window.