Skip to content
Star17Hire me
01 / StartXP 0%
Sep 4, 2026 · 1 min · by Ahmed Mamdouh

Caching mistakes I keep debugging

#caching#redis#performance#system-design

Before you add a cache, answer one question: what invalidates it? Every caching bug I have debugged came down to skipping that question, or to one of the three mistakes below.

The question to answer first

If answering "what invalidates it?" takes longer than thirty seconds, or ends with "we'll figure that out later", what you're adding is a second source of truth. It will disagree with the first one at some point you can't predict.

Half the caching bugs I have debugged had little to do with the cache itself. Nobody had decided, on the day it shipped, when the data was allowed to go stale.

Caching before measuring

One endpoint I looked at was slow because of an N+1 query. The cache hid that until traffic doubled, and then the query was back with twice the load behind it. Put a cache in front of a slow path you haven't explained and you've only postponed the problem.

No TTL strategy

"We'll invalidate manually" is a promise your future self will break. Even with explicit invalidation in place, set a TTL. It catches the case you forgot to invalidate.

Caching the wrong thing

A common one is caching the final computed result when only one piece of it was expensive. Then a single field changes and you rebuild everything. Cache the expensive piece and assemble the cheap parts around it on each request.

My rule now is to cache late and cache small. It's not exciting, but the pager stays quiet.

Building something like this?

I'm Ahmed Mamdouh, a senior full-stack and AI engineer. I reply within one working day.

More posts