A sticky note on your monitor

The problem: doing the same expensive work, over and over

Somewhere in your app, something slow keeps happening for no good reason: a database query that scans a big table, an API call to a third party, a calculation that takes real CPU time. It runs once. Then, thirty seconds later, someone asks the exact same question, and your system dutifully does all that work again — same query, same answer, same cost.

What caching actually does

A cache sits between the request and the expensive work. Before doing the slow thing, you check: have I already computed this? If yes, hand back the stored answer immediately. If no, do the slow work once, then store the result before returning it — so the next request gets the shortcut.

That's the entire idea. Everything else — Redis, CDNs, browser caches, memoization in code — is just this pattern applied at a different layer of the stack.

The catch: stale answers

A cache is only useful if the stored answer is still true. If the underlying data changes and the cache doesn't know, you're now confidently handing out a wrong answer, fast. This is why cache invalidation — deciding when a stored answer expires or needs updating — is the genuinely hard part of caching, not the storing itself.

When to reach for one

Cache things that are expensive to produce, requested often, and safe to serve slightly stale. Don't cache things that change every request or where staleness is dangerous — a bank balance is a worse candidate than, say, a list of blog post titles.