Cache keys are equivalence claims

List every input that can change the response: tenant identity, resource identity, selected fields, locale, format, feature configuration, and source version where relevant. Authorization needs particular care. A tenant-scoped key may still be too broad when users in that tenant have different visibility. Recheck permissions at the appropriate boundary and decide whether entries represent public, role-scoped, user-scoped, or permission-versioned data. A correct identifier does not make a previously authorized result safe after permissions change.

A raw bearer token is generally a poor cache-key component because it exposes a secret and fragments entries unnecessarily. Prefer a stable nonsecret authorization scope or a deliberate private-cache policy, while preserving the actual access-control decision. For HTTP shared caches, follow the protocol's Authorization and cache-control rules rather than implementing an informal application rule. Vary identifies relevant request-header dimensions, but does not automatically capture every application-specific tenant or permission distinction.

Sorting independent named parameters can make equivalent requests share a key, but repeated parameters, order-sensitive filters, Unicode normalization, case, and missing-versus-empty values may change meaning. Apply transformations only when the API contract establishes equivalence. Use a structured, unambiguous encoding, such as length-prefixed fields or a precisely specified serializer. Naive concatenation can make different tuples identical before hashing, which no stronger digest can repair. Test both equivalences and intentionally distinct near-collisions.

Namespace keys by schema or representation version so a deployment can change the stored shape without interpreting old bytes incorrectly. Bound key lengths and reject unsupported input combinations. A digest can compact a canonical encoding, but digest collision handling and operational debuggability still need a policy. Avoid logging sensitive canonical contents merely to debug hit rates. Store enough nonsecret metadata to identify the key schema and scope without recreating a credential or personal-data leak.

Create paired requests that should share a response and paired requests that must remain separate. Include tenants with overlapping resource identifiers, permission changes, locale differences, missing parameters, and repeated fields. Check the actual returned data and authorization result, not just generated strings. A warm-cache test matters because a cold request can consult the origin and conceal a flawed reuse decision. During a key-schema rollout, measure temporary duplicate storage and cold-origin load as well as correctness.

The cache lab demonstrates key identity only as a toy address trace. Reset and set both C=4, s=4; predict four distinct identifiers and twelve hits among the initial sixteen requests, then Step to add one hit. The fully associative empty-start LRU trace requests (i×s) mod 16 and caps at 4096 requests. It has no tenant, permission, or representation context. Its successful hits therefore cannot validate an application's equivalence relation; explain which extra key dimensions would make those reused values safe.