Imagine an endpoint that returns a price. A key containing only the product ID looks reasonable until the price also depends on currency, customer tier or region. Those inputs are part of the result even if they do not appear in the URL.

1

cache_key = (product_id, currency, customer_tier, pricing_version)

This is an illustrative key, not a complete pricing design. Its purpose is to make the dependencies visible. If account-specific permissions affect the response, those boundaries also need to be reflected in the caching strategy.

Freshness is a product decision

A five-minute-old avatar and a five-minute-old available balance carry different consequences. A time-to-live is meaningful only after someone decides what stale data is acceptable for that operation.

Expiry also does not solve every invalidation problem. An update followed immediately by a read can still return an old cached value. Options include invalidating on writes, versioning keys or accepting a documented delay. Each choice creates different failure modes.

Check the uncomfortable cases

Before measuring a hit rate, I would check that:

• Two users cannot receive each other’s private result.
• A change in an input that affects the result changes the cache lookup.
• An update behaves as promised on the next read.
• A cache outage has an intentional failure or fallback path.

For HTTP caches, headers add another layer to this contract. no-cache permits storage but requires validation before reuse; no-store tells a cache not to store the response. They are not interchangeable ways to say “please be fresh.”

A cache is easier to operate when its correctness rule fits in a sentence. The performance measurements come after that rule is clear.

Reference: HTTP caching specification, RFC 9111.