A cache key is a claim that two answers are interchangeable

First, build a mental model

A cache reuses a previous result for a key. If two requests share a key, you are claiming the cached result is valid for both under the cache's freshness rules.

1. Name the cache: build output, framework data cache, browser memory, HTTP cache and service-worker cache have different lifetimes and controls.
2. Include every answer-changing dimension in the cache scope or key. User, company, query and permission changes can affect whether a result is reusable; a correct key still does not replace authorization.
3. Define invalidation and staleness explicitly. An older request can arrive after a newer one, so cancellation or response-version checks may be needed even without a persistent cache.
4. HTTP Cache-Control influences response reuse: public permits shared-cache use, private restricts shared caching, and no-store forbids storage by compliant caches. Framework caching defaults vary with version/configuration; inspect the actual contract.

type Scope = { actorId: string; companyId: string; query: string };
export function resultKey(scope: Scope): string {
  return JSON.stringify([scope.actorId, scope.companyId, scope.query]);
}
// A browser-memory key for synthetic private search results.
// Revalidate authority and clear relevant state on identity changes.

1. Request A

   Alice, company A and query 'lamp' produce a specific key.

2. Request B

   Bob, company B and the same query must not silently reuse Alice's private result.

3. Freshness

   Even Alice's key can become stale after a write or permission change; scope and freshness are different questions.