cachinglisted

# Caching A cache that is wrong is worse than no cache. A slow page annoys someone; a stale page misinforms them, and a mis-keyed one shows them somebody else's data. So this starts with the failure modes, and the mechanics come after. **Come here second.** A cache is one rung of a larger decision, and work that could have moved up a rung should never be hidden behind one instead. `davinci:work-placement` makes that call and sends you here when the answer really is a cache. ## 1. The cache key is a security boundary This is the one that turns a performance change into an incident. If a response depends on **who is asking** — a session, a role, a tenant, a locale, a feature flag — then every one of those inputs belongs in the key. Miss one and the first user's response is served to the second. ``` BAD key: `dashboard` one cache, every user GOOD key: `dashboard:${tenantId}:${userId}:${role}` ``` The same rule at the HTTP layer: a response that varies by cookie or authorization header must never be `public`. If a CDN or proxy can hold it, assume it will. ``` Cache-Control: private, no-store anything user-specific Cache-Control: public, max-age=31536000, immutable fingerprinted static assets ``` **Ask of every cached value: could two different people get the same entry, and would that be wrong?** If yes, the key is incomplete. Write down the answer in your report — this is not a detail to leave implicit. ## 2. Invalidation is the des