On this page
What Is Caching (and the Most Common Ways to Get It Wrong)?
A cache stores frequently used data for fast retrieval. Learn how caching works, why it helps, and the classic ways to get it wrong.
Quick answer
- A cache stores copies of expensive-to-compute data so repeated requests are served fast.
- It trades memory for speed, and it’s one of the most effective performance wins available.
- The hard part is invalidation: keeping the cache consistent with the source of truth.
What is caching?
Caching is storing a copy of data in a faster place so that future requests can be served without recomputing it. The cache might live in memory (Redis, Memcached), in the browser, or at a CDN edge. When a request arrives, the system checks the cache first; on a hit, it returns instantly; on a miss, it computes, stores, and returns. The principle is simple: don’t redo expensive work.
Why it matters
A cache can turn a 200 ms database query into a sub-millisecond memory lookup, and multiply the requests a server can handle. For hot data — a popular product page, a shared config, a computed feed — caching is often the single biggest performance win, and cheaper than adding servers.
The common mistakes
Caching fails in predictable ways. Stale data — the cache serves an old value because invalidation didn’t run. Cache stampede — an expired hot key triggers a flood of simultaneous recomputes. Wrong key design — cache keys that collide or never hit. Caching the wrong thing — caching data that changes constantly, so you pay invalidation cost for no hits. And the classic: caching your primary database reads without a plan for keeping them consistent.
Where this bites vibecoders
AI assistants add caching eagerly — “let’s cache this” is an easy suggestion — but rarely add the invalidation story, so the app serves stale data after a write. The rule that matters: the cache is a performance layer, not a source of truth. If you can’t answer “when does this get invalidated?” for every cache, the cache will eventually serve wrong data to a real user.
Where AI coding assistants get this wrong
- Adding a cache with no invalidation, so writes don’t reflect in reads.
- Caching user-specific data under a shared key, leaking one user’s data to another.
- Forgetting cache stampede protection on hot keys.
- Caching values that are cheaper to recompute than to keep consistent.
Checklist
- Treat the cache as a performance layer, never the source of truth.
- Define invalidation for every cached value before enabling it.
- Use distinct, namespaced keys — never shared keys for user data.
- Add stampede protection for hot, expensive keys.
- Measure hit rate; cache only what’s actually hot.
FAQ
What is cache invalidation?
Invalidation is the process of removing or updating cached values when the underlying data changes, so the cache doesn’t serve stale data. It’s famously one of the two hard problems in computer science (with naming things), because getting it right in every case is genuinely difficult.
What is a cache stampede?
A stampede happens when a hot key expires and many requests simultaneously miss, recompute, and write back — often overwhelming the database. Protection strategies include locking the recompute, serving stale data briefly, or jittering expiry times.
Is caching the same as indexing?
No, they solve different slowness. An index speeds up finding rows in a database; a cache avoids querying at all by storing a copy in faster storage. They’re complementary: index for query speed, cache for repeated reads. See What Is Database Indexing?.