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
The moment your most popular cache key expires, hundreds of requests pile onto the database in the exact same second.
What you'll have at the end
A lock that lets only one request rebuild the hot key while everyone else waits for the fresh value
You need
A route that already checks a cache before running a fairly expensive query against Postgres, writing the fresh result back with a short expiry once it lands; what happens today when hundreds of requests land on that same key in the same expiring instant is the part this recipe replaces.
Not covered
Coordinating the same lock across several independent cache nodes so one node going down can't be mistaken for the lock still being free; that coordination problem is its own topic once a single cache node stops being enough.
Leans on
Add a cache-aside layer in front of one query
builds the basic check-then-fetch-then-write flow this recipe assumes is already running, starting from a route with no cache at all.
Turn on negative caching so a missing lookup stops hitting Postgres
a stampede of repeated misses on a key that never has a value, rather than a hot key's fresh value expiring, is this same pile-up in its negative-caching form.
Prove your cache is faster, never slower
measuring whether this lock is actually paying for itself under real traffic, instead of the worked numbers here, belongs there.
Checked 19 Aug 2026
Part of the Backend Caching cookbook