There’s an old joke that there are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. The joke endures because caching is everywhere and genuinely tricky. It’s also one of the single biggest performance wins available to any developer. Understanding what caching is and how to use it well can make an application feel dramatically faster with surprisingly little effort.
What caching is
Caching is the practice of storing a copy of data somewhere fast, so that future requests for that data can be served quickly instead of being recomputed or re-fetched from a slow source. The slow source might be a database, an external API, or an expensive calculation. The cache is a fast shortcut that says, “I’ve seen this before — here’s the answer I saved.”
The principle behind it is that a lot of work is repetitive. The same data gets requested over and over. Instead of doing the full expensive work every single time, you do it once, remember the result, and reuse it. That reuse is where the speed comes from.
Why it’s such a big deal
The performance difference can be enormous. Reading a value from an in-memory cache might take microseconds, while querying a database for the same value could take tens of milliseconds — hundreds of times slower. On a busy site, caching also dramatically reduces load on your database and servers, because most requests are answered from the fast cache and never touch the expensive backend. Faster responses and less load is a rare win-win.
Where caching happens
Caching occurs at many layers, often several at once:
- Browser cache — your browser stores images, CSS, and JavaScript locally so it doesn’t re-download them on every page.
- CDN cache — content delivery networks cache assets on servers near users worldwide.
- Application cache — a fast store like Redis or Memcached holds frequently used data in memory.
- Database cache — databases themselves cache query results and frequently accessed data.
A single page load might benefit from all of these working together, each catching repeated requests at a different level.
The hard part: cache invalidation
Here’s where the famous difficulty lives. A cache holds a copy of data, and copies go stale when the original changes. If a user updates their profile but the cache still serves the old version, they see wrong information. Cache invalidation is the problem of deciding when to remove or refresh cached data so nobody sees outdated results — and it’s genuinely hard because you’re balancing freshness against performance.
The core tension is this: cache too aggressively and users see stale data; cache too little and you lose the performance benefit. Every caching strategy is really a way of navigating that trade-off.
Common strategies for keeping caches fresh
- Time-based expiration (TTL) — give cached data a lifespan; after it expires, the next request refreshes it. Simple and widely used.
- Event-based invalidation — when the underlying data changes, actively delete or update the cached copy so it’s rebuilt fresh.
- Cache-aside — the app checks the cache first; on a miss, it fetches from the source, stores the result, and returns it.
Which you choose depends on how tolerant your data is of being slightly out of date. A stock price needs near-instant freshness; a blog post can be cached for hours.
What to cache — and what not to
Cache data that’s read often, changes rarely, and is expensive to produce — that’s the sweet spot. Be cautious caching data that’s highly personalized, changes constantly, or is sensitive. And always ask “how bad is it if this is a little stale?” before caching something; the answer guides how long you can safely keep it. Caching the wrong things causes subtle, maddening bugs, so cache deliberately, not reflexively.
Cache-aside in real code
The cache-aside pattern is the workhorse of application caching, and it’s short enough to show whole:
async function getUser(id) {
const cached = await redis.get(`user:${id}`);
if (cached) return JSON.parse(cached); // hit: microseconds
const user = await db.query('SELECT * FROM users WHERE id = ?', [id]);
await redis.set(`user:${id}`, JSON.stringify(user), 'EX', 300); // TTL 5 min
return user; // miss: paid the DB cost once
}Three details in those few lines carry most of caching’s craft. The key (user:${id}) follows a namespaced convention so related entries are findable and deletable as a group. The TTL (300 seconds) caps staleness even if invalidation never fires — a safety net every cached value should have. And on updates, you’d add one line to the write path: redis.del(`user:${id}`), so the next read rebuilds fresh. Delete-on-write plus TTL-as-backstop is the combination that keeps most production caches honest.
The failure modes veterans watch for
Caching has a few classic pathologies worth knowing before they find you. A cache stampede happens when a popular entry expires and a thousand concurrent requests all miss simultaneously — and all hammer the database at once to rebuild the same value. Mitigations include letting one request rebuild while others briefly serve the stale value, or jittering TTLs so entries don’t expire in synchronized waves.
Cache penetration is the sneaky one: requests for keys that don’t exist (a bad ID, or an attacker probing) always miss the cache and always hit the database, bypassing your protection entirely. The fix is caching the negative result too — remember “user 999999 doesn’t exist” for a minute, and repeated probes cost nothing.
And the subtlest: treating the cache as a source of truth. Caches are allowed to vanish — Redis restarts, memory pressure evicts entries. If your application breaks (rather than merely slows down) when the cache is empty, you’ve accidentally built a database with amnesia. Every cached value must be rebuildable from the real source at any moment.
How to know your cache is actually working
Measure, don’t assume. The number to watch is the hit ratio — hits divided by total lookups. A well-tuned cache on read-heavy data often exceeds 90%; a ratio under 50% means you’re paying cache complexity for little benefit, usually because TTLs are too short, keys are too specific (every request slightly different), or the data simply isn’t re-read often enough to cache. Most cache layers expose these stats cheaply — Redis’s INFO stats shows keyspace hits and misses directly. Check the ratio once after launching, and again whenever the database feels busier than it should.
Frequently asked questions
Redis or Memcached? Both are excellent in-memory caches. Redis has become the common default because it does more — rich data structures, persistence options, pub/sub — while Memcached remains a lean, purpose-built cache. If you just need get/set with TTLs, either serves; if you’ll ever want more, Redis spares you a migration.
How long should my TTL be? Ask “how stale can this be before someone notices or something breaks?” and set the TTL comfortably below that. Product catalog descriptions might tolerate hours; a shopping cart, seconds. There’s no universal number — staleness tolerance is a per-data-type business decision.
Should I cache database query results or rendered output? Both are valid at different layers. Caching query results (objects) is flexible — many pages can reuse them. Caching final rendered output (HTML fragments, API responses) saves the most work per hit but is invalidated by more kinds of changes. Busy systems often do both: objects in Redis, pages at the CDN.
The takeaway
Caching stores copies of expensive-to-get data somewhere fast, so repeated requests are answered instantly instead of redone — a massive win for both speed and server load. The catch is invalidation: keeping cached copies from going stale as the real data changes. Master the balance between freshness and performance, cache the right things at the right layers, and you hold one of the most powerful tools for building fast, scalable applications.
