Use cache keys and TTLs safely

Identify cacheable data

Choose repeatable read queries that tolerate staleness. Avoid caching personalized responses under shared keys, even if those responses look similar.

Establish a key convention

site:product:123:v1
site:category:maps:v1

Keys should incorporate all inputs that influence the response. Include the tenant/user identifier for access-scoped values.

TTL and invalidation

Choose short TTLs for frequently changing facts and invalidate keys after relevant updates. Do not rely on expiry alone for sensitive permissions or payment state.

Error fallback

When the cache is unavailable, the application should preserve correctness by falling back to the durable data store with bounded load. Test stampedes and retry behavior.

Monitoring

Measure hit rate, eviction rate, memory usage and expired keys. Test authorization behavior on cache hits. Read Redis documentation before adopting commands or features.