Caching Explained

Caching is the #1 performance lever you have. Not code splitting. Not lazy loading. Not switching to a faster framework. Caching. A single well-placed cache layer can turn a 2-second API call into a 5-millisecond response — and it works at every level of your stack.

The challenge is knowing where to cache, what strategy to use, and how to invalidate without serving stale data. This guide breaks down all four layers of caching, the strategies behind them, and the mistakes that trip up even experienced developers.

What Is Caching?

Caching is storing the result of an expensive operation so you can serve it again without repeating the work. The "expensive operation" could be a database query, an API call, a computation, or even rendering an entire page.

Think of it like a sticky note on your monitor. Instead of looking up your team's standup time every day, you check the sticky note. The information hasn't changed — so why look it up again?

Every caching system has the same core flow:

1. Request comes in
2. Check cache → HIT? Return cached result (fast path)
3. MISS? Execute the expensive operation
4. Store result in cache with TTL
5. Return result to caller

The key decisions are: what to cache, where to cache it, how long to keep it, and how to remove it when it's wrong. The rest of this guide covers exactly that.

The 4 Layers of Caching Explained

Caching isn't a single technique — it's a strategy applied at multiple levels. Each layer catches different types of redundant work, and they stack on top of each other.

Comparison: All 4 Caching Layers

Here's how the layers stack up side by side:

Caching Strategies

Not all caches work the same way. The strategy determines who's responsible for populating and updating the cache. Here are the four main patterns:

Cache-Aside (Lazy Loading)

The application manages the cache directly. On read, it checks the cache first. On miss, it fetches from the database, stores the result in cache, then returns it. On write, the application invalidates (or updates) the cache entry.

// Cache-Aside pattern
async function getUser(userId) {
  // 1. Check cache
  const cached = await redis.get(`user:${userId}`)
  if (cached) return JSON.parse(cached)

  // 2. Cache miss — fetch from DB
  const user = await db.users.findById(userId)

  // 3. Populate cache with TTL
  await redis.setex(`user:${userId}`, 300, JSON.stringify(user))

  return user
}

Most common pattern. You control exactly what gets cached and when.

Read-Through

The cache sits between the application and the database. On miss, the cache itself fetches from the database — the application doesn't need to know about the data source. Libraries like cacheable or AWS DAX implement this pattern.

Benefit: cleaner application code. Downside: less control over what happens on a miss.

Write-Through

Every write goes to the cache first, then the cache writes to the database synchronously. The cache is always up-to-date, so reads never see stale data. The trade-off is higher write latency since both stores must confirm.

Good for read-heavy workloads where consistency matters (user sessions, account balances).

Write-Behind (Write-Back)

Writes go to the cache immediately, but the cache flushes to the database asynchronously in batches. This gives you very fast writes, but introduces a window where the database is behind the cache. If the cache crashes before flushing, you lose data.

Used for high-throughput writes where temporary inconsistency is acceptable (analytics, view counters, activity feeds).

Cache Invalidation Strategies

"There are only two hard things in Computer Science: cache invalidation and naming things." Phil Karlton wasn't joking. Here are the approaches that actually work:

TTL-Based Expiration

Set a time-to-live on every cache entry. After it expires, the next request fetches fresh data. Simple and predictable. The downside: data can be stale for up to the entire TTL duration.

// Redis TTL — expires after 5 minutes
await redis.setex('product:123', 300, JSON.stringify(product))

// HTTP Cache-Control — browser caches for 1 hour
res.setHeader('Cache-Control', 'public, max-age=3600')

Event-Driven Invalidation

When data changes, immediately delete or update the related cache entries. This gives you near-zero staleness but requires you to know exactly which cache keys are affected by each write operation.

// After updating a user
await db.users.update(userId, newData)
await redis.del(`user:${userId}`)        // Delete specific key
await redis.del('users:list:page:1')     // Invalidate related list

Versioned Keys

Include a version number in the cache key. When data changes, increment the version. Old entries naturally expire via TTL while new requests use the updated key.

// Version-based cache key
const version = await redis.get('products:version') // e.g., "7"
const cacheKey = `products:v${version}:page:${page}`

// On product update — increment version
await redis.incr('products:version')
// All old cache keys (v7) become orphaned and expire via TTL

Purge / Manual Invalidation

Explicitly purge specific URLs or cache entries through an API or admin interface. CDNs like Cloudflare and Fastly support instant purge by URL, tag, or entire zone. Useful for content publishing workflows where editors need changes live immediately.

Code Examples

Redis Caching in Node.js

A complete cache-aside implementation with error handling and TTL:

import Redis from 'ioredis'

const redis = new Redis(process.env.REDIS_URL)

async function cached(key, ttlSeconds, fetchFn) {
  try {
    const hit = await redis.get(key)
    if (hit) {
      console.log(`Cache HIT: ${key}`)
      return JSON.parse(hit)
    }
  } catch (err) {
    // Cache failure shouldn't break the app
    console.warn('Cache read error:', err.message)
  }

  // Cache miss — execute the expensive operation
  const result = await fetchFn()

  try {
    await redis.setex(key, ttlSeconds, JSON.stringify(result))
    console.log(`Cache SET: ${key} (TTL: ${ttlSeconds}s)`)
  } catch (err) {
    console.warn('Cache write error:', err.message)
  }

  return result
}

// Usage
const user = await cached(
  `user:${userId}`,
  300, // 5 minutes
  () => db.users.findById(userId)
)

HTTP Cache-Control Headers

Setting proper cache headers in Express/Next.js:

// Static assets — cache for 1 year (use content hash in filename)
app.use('/static', express.static('public', {
  maxAge: '1y',
  immutable: true
}))

// API response — private, short cache, revalidate in background
app.get('/api/products', (req, res) => {
  res.setHeader('Cache-Control', 'private, max-age=60, stale-while-revalidate=300')
  res.setHeader('ETag', computeETag(products))
  res.json(products)
})

// HTML pages — always revalidate, but use ETag for 304 responses
app.get('/dashboard', (req, res) => {
  res.setHeader('Cache-Control', 'no-cache') // must revalidate every time
  res.setHeader('ETag', `"${pageVersion}"`)
  res.render('dashboard')
})

// Sensitive data — never cache
app.get('/api/user/billing', (req, res) => {
  res.setHeader('Cache-Control', 'no-store')
  res.json(billingData)
})

React Query / TanStack Query — Stale Time

Client-side caching with automatic background refetching:

import { useQuery } from '@tanstack/react-query'

function ProductList() {
  const { data, isLoading } = useQuery({
    queryKey: ['products'],
    queryFn: () => fetch('/api/products').then(r => r.json()),
    staleTime: 5 * 60 * 1000,        // Consider fresh for 5 minutes
    gcTime: 30 * 60 * 1000,           // Keep in cache for 30 minutes
    refetchOnWindowFocus: true,        // Refetch when user returns to tab
    refetchOnReconnect: true,          // Refetch after network recovery
  })

  // Data is served instantly from cache on subsequent renders
  // Background refetch happens silently after staleTime expires
}

Common Caching Mistakes

These trip up developers at every level. Avoid them:

Caching Best Practices

Frequently Asked Questions

When NOT to Cache

Not everything benefits from caching. Some data should always come fresh from the source:

Measuring Cache Effectiveness

A cache you can't measure is a cache you can't trust. Track these metrics:

Redis provides these metrics via INFO stats (keyspace_hits, keyspace_misses). For CDNs, check your provider's analytics dashboard. For browser caching, use Chrome DevTools Network tab and look for "(disk cache)" or "(memory cache)" indicators.

Related Articles & Tools

Conclusion

Caching is not optional for production applications. It's the difference between a 2-second response and a 5ms response, between handling 100 requests/second and 10,000. But it's not magic — you need to choose the right layer, pick the right strategy, and have a plan for invalidation.

Start simple: add Cache-Control headers to your static assets and use Redis for your most expensive database queries. Measure hit rates, watch for stale data issues, and layer in more caching as you understand your access patterns. The fastest request is the one that never hits your server.