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
Everything works with one server and a plain in-memory dictionary as a cache, then you add a second server and the two stop agreeing.
What you'll have at the end
A written decision, with the reason, for whether this piece of data lives in an in-process cache or a shared Redis cache
You need
A backend already running as more than one instance behind a load balancer, with at least one value currently cached in a plain in-process dictionary that two instances have already answered differently for.
Not covered
Writing the actual cache-aside code once you've picked a tier, and tuning whichever cache you land on afterward: both are their own decision once this one is made.
Leans on
Add a cache-aside layer in front of one query
once the decision here lands on Redis, this is the actual read-check-populate code to wire in front of the query.
Fix a cache that shows old data
if the real complaint is staleness after a database write rather than two instances disagreeing right now, invalidation is the actual fix.
Move a user's session lookup out of Postgres
when the value in question is specifically a user's session, this walks the Redis move itself instead of just the decision.
Checked 19 Aug 2026
Part of the Backend Caching cookbook