Client-side server-state cache

Callers ask for a subscriber's number; she keeps a card for each name-and-town she has looked up.

At the switchboard	In the query cache
one card per name-and-town	one entry per key (step 1)
two callers ask for the same name while she is already looking it up; both hear that one lookup	a shared in-flight request (step 3)
a card written within the hour is read out without opening the directory	fresh, no request (step 4)
an older card is read out at once, and she checks the directory and corrects it	stale shown, refetched (step 5)
cards nobody has asked for in a week go in the bin	gcTime (step 7)
the exchange's notice "district 4 renumbered" marks every district-4 card "check"; callers still on the line are checked now	invalidation by prefix (step 9)
a subscriber's new number goes on the card at once, marked provisional, and the old card goes back if the exchange rejects it	optimistic patch, rollback (steps 10–11)

In real terms: each key holds one remembered answer, shared by every component that asks, reused while fresh, refreshed while shown, and dropped when unused.

Breaks down when: an operator notices an answer that does not fit the question. The cache never checks: whatever a fetch returns becomes the key's entry (step 6). Wrong inference: "the cache knows which data each component wanted."

Contrasting case: an operator with no card box, who opens the directory for every call, even for a name asked a minute ago. That is a fetch in each component's effect.

4.1 ExamHall: the proctor console's Tiles tab (EXH-1470)

Forty candidate tiles each need ECON-201's exam metadata. The proctor opens Tiles, then Alerts, Tiles, Alerts, Tiles.

4.1 fetch in each tile's effect, into a store  metadata requests per Tiles visit 40, 40, 40 (total 120)
4.1 useQuery, default staleTime 0              metadata requests per Tiles visit 1, 1, 1 (total 3)
4.1 useQuery, staleTime: Infinity (MR !1670)   metadata requests per Tiles visit 1, 0, 0 (total 1)
4.1 alert list (staleTime 0, every version)  requests per Alerts visit 1, 1 · first frame spinner | 3 alerts (cached)

A store filled from forty effects fetches forty times. One key makes it one request (steps 1, 3). Exam metadata cannot change during a sitting, so MR !1670 marks it fresh forever. The alert list keeps staleTime 0: shown at once, refetched on every return (step 5).

4.2 Proof domain, catalog: one product page on the clock

A product page uses staleTime: 60_000. The shopper leaves and returns three times.

4.2 first visit                requests 1 · shows spinner > €49
4.2 back after 30 s            requests 0 · shows €49
4.2 back 3 min later           requests 1 · shows €49 > €45
4.2 back 7 min later           requests 1 · shows spinner > €44
4.2 keys {category, size} in either order: 1 entry · ['products','boots',42] vs ['products',42,'boots']: 2 entries · 4 components -> 3 entries, 3 requests

At 30 s the entry is fresh (step 4); at 3 minutes it is stale, shown and refetched (step 5); 7 minutes unused passes gcTime, so the entry is gone (step 7). Object keys match in any order; array order counts (step 2).

4.3 ExamHall: acknowledging an alert (EXH-1471)

A proctor acknowledges alert a-17; the tile patches optimistically. Another proctor has already escalated it, so the server answers 409.

4.3 patch, no rollback (before MR !1671)       open > acknowledged · alert requests 1
4.3 patch + rollback + invalidate, server OK   open > acknowledged · alert requests 2
4.3 patch + rollback + invalidate, server 409  open > acknowledged > open > escalated · alert requests 2

Without a rollback the tile keeps a status the server refused. MR !1671 restores the snapshot, then invalidates, so the tile ends as the server says (steps 10–11).