Caching at Every Layer

Caching stores the result of an expensive operation so future requests return instantly without repeating the work. It exists at every layer: the browser caches responses via Cache-Control headers, a CDN caches content at edge locations, the application caches database results in Redis, and the database itself caches hot pages in its buffer pool.

The hardest caching problem is invalidation — knowing when to evict stale data. Write-through caches update the cache on every write, staying consistent at the cost of slower writes. Cache-aside is the most common: read from cache, fall through to the database on miss, then populate the cache for next time. Use TTLs as a safety net so stale data cannot live forever even if invalidation logic misses.

Before

No cache — every read hits the database

1// 580 feed reads/sec all hit Postgres directly2async function getUserFeed(userId: string) {3  return db.query(`4    SELECT p.* FROM posts p5    JOIN follows f ON f.followee_id = p.author_id6    WHERE f.follower_id = $17    ORDER BY p.created_at DESC LIMIT 208  `, [userId]);9}

After

Cache-aside — hot feeds served from Redis

1async function getUserFeed(userId: string) {2  const key = `feed:${userId}`;3  const cached = await redis.get(key);4  if (cached) return JSON.parse(cached);5 6  const feed = await db.query(/* sketch: expensive join */);7  // Cache for 60s — feed can be slightly stale8  await redis.setex(key, 60, JSON.stringify(feed));9  return feed;10}

Check your understanding

What is cache-aside?Show answerHide answer
Answer
App checks cache, loads DB on miss, then populates the cache — app owns the flow.
Why use TTLs even with explicit invalidation?Show answerHide answer
Answer
As a safety net when an invalidation is missed so stale data cannot live forever.
Where can caches live?Show answerHide answer
Answer
Browser, CDN, app memory, Redis/Memcached, and DB buffer pools — among others.