New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
Redis is either silently forgetting keys you still need, or it has stopped accepting writes altogether, and you don't know which policy is even set.
What you'll have at the end
The eviction policy matched to what each Redis instance actually holds: sessions on their own instance where the evicted-keys count stays at zero, and cache on its own instance where the same count is expected to climb and is watched for a change in rate, not for its existence.
You need
A Redis instance already under real write traffic, holding both a query cache with a TTL on every entry and something else, like session tokens, that has no TTL and must not be lost.
Not covered
Sizing the Redis instance itself, or building the session store from scratch: both are their own decision once the policy question here is settled.
Choose local caching or Redis
if the open question is which tier a value belongs on at all, settle that first: an eviction policy only matters once the value is already on Redis.
Move a user's session lookup out of Postgres
for moving sessions into Redis in the first place, before an eviction policy for them is even a question.
Checked 19 Aug 2026
Part of the Backend Caching cookbook