Cache keys encode response-changing inputs

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

TA/TB use one report URL with different locale/permissions. A URL-only cache can serve the first viewer’s response to another. Teaching keys must include response-changing context.

Mechanism

Trace report dependencies: data/version, tenant, viewer/effective authorization, locale and flags. Encode keys unambiguously without secret logging and define freshness/invalidation/versioning. Recheck current permission instead of cached old authority; freshness-critical responses need their contract. Content hashes suffice only when content/configuration truly determine results.

Bad example

Cache /report alone and reuse TA/Chinese/admin output for TB/English/member as a speed win.

Good example

Key teaching reports by version, tenant, locale and actual viewer/permission dependencies. TA/zh/admin cannot share TB/en/member. State staleness/invalidation and recheck permission changes, retaining identity without treating path/hash as universal.

Why the change matters

Reuse assumes equal response inputs; missing dependencies can cross identity boundaries. Complete keys/freshness preserve correctness alongside speed.

Observable expectation

Identical context can hit; changed tenant/locale/permission misses. New data versions cannot use old keys. Revoked permission cannot retain admin response access. Check request/output identity, not hit rate alone.

Limits

Dependencies can evolve and complete keys do not themselves authorize. Cardinality/stampede need design and TTL does not provide real-time correctness. Apply frozen examples to actual contracts without current cost/performance claims.