A client cache maps a request identity to a result. Its key must include every input that changes the response: record ID, filter, page, locale when content differs, and account or tenant boundary where relevant. An incomplete key makes two distinct screens share data. After a write, invalidate or update the exact affected records and lists. A record detail and a filtered queue can both describe the same case, so refreshing one does not necessarily repair the other. Start with a small key vocabulary that matches server request contracts, and keep private caches isolated at sign-out or account switch.
Make this comfortable
Client Cache Keys and Invalidation
Working case
A reviewer resolves case 47 while viewing the Pending queue. The detail panel changes to Resolved, but the Pending list still contains 47 because only the detail key was updated. If the list key omits filter and account, another route may even reuse the wrong queue. Define separate keys for the case record and each queue filter. On successful resolution, update or invalidate the case detail, the Pending list, and the Resolved list. A version in the server response can prevent an older background fetch from overwriting a newer mutation result.
Implementation boundary
function caseKey(accountId, caseId) { return ["case", accountId, caseId]; }
function queueKey(accountId, state, page) { return ["queue", accountId, state, page]; }
console.log(JSON.stringify(caseKey(29, 47)));
// Output: ["case",29,47]Use stable primitive key parts; avoid putting a freshly created object in a key unless the cache library normalizes it predictably. Keep a dependency map from a mutation to affected views: detail, membership lists, counters, and any search result that displays status. Invalidate when computing the replacement is hard or partial; write through when the server response contains the authoritative next record. In either case, guard against a fetch started before the mutation completing afterward. A query cache is a view optimization, never the authority for write authorization.
Cost and boundaries
A key lookup is usually near O(1) in a map-backed cache, but invalidating m related views can trigger up to m network reads and renders. Broad invalidation is simpler and potentially costly; narrow updates are faster but can miss a view. Cache memory grows with distinct account, filter, page, and record combinations, so expiration and sign-out clearing matter. Measure stale membership bugs and duplicate fetches together. The right policy is the smallest reliable set of affected views, not the smallest possible line count.
Failure trace
The key ['queue', 'Pending'] omits account ID. Reviewer 29 switches to an account that should not see case 47; the old list remains visible until a refetch finishes. A second defect appears when a background Pending request started before resolution returns after the mutation and puts 47 back in the list. Include account scope in keys, clear private data on account switch, cancel or version stale requests, and invalidate every list whose membership can change. Test with delayed responses, not only fast local networking.
Verification
- A resolved case leaves Pending and appears in Resolved after the write.
- Delayed old reads cannot replace a newer result.
- Account switches expose no rows from the prior account.
Practice drill
Create Pending and Resolved queues for accounts 29 and 62, then resolve case 47. Record which keys change and which fetches run. Delay a pre-mutation Pending response until after the write succeeds; 47 must not reappear. Switch accounts without a page reload and check for any old private row. Add page and filter variants, then verify a key change actually produces a different cache entry. Document how the cache expires when the tab stays open for an hour.
Decision note
Key by the whole response identity and invalidate the complete set of views whose content or membership the write changes.
Common Mistakes
- Leaving filter or account scope out of a key.
- Refreshing a detail record but forgetting list membership.
- Assuming an old request cannot finish after a newer write.
Connected lessons
Server Rendering and Client Data Flow; Hydration and Deterministic First Render; Server Data Bootstrap and Freshness; Optimistic Mutations and Rollback; HTTP caching: validate a changed representation with an ETag; Conditional Writes and Lost-Update Prevention; Authorization: check permission for this record on every request.
Apply and check
Build Project: server-rendered case queue and review Web Development: rendering and forms decisions quiz.
Further connections
Back-Forward Cache and Restored State.
Further connections
web-tech
web-development