Caching Strategies That Actually Scale: CDN, ISR and Redis Explained

the fastest request is the one you never make. caching is how you avoid recomputing the same answer over and over — and done well, it is the single highest-leverage performance change you can ship. but "just add a cache" hides a stack of decisions. here is how the layers fit together.

the caching pyramid

think of caching as layers, each one closer to the user than the last:

1. browser cache — on the user's device, zero network.
2. cdn / edge cache — close to the user, geographically distributed.
3. rendered-page cache (ISR) — pre-built html the server can reuse.
4. application cache (Redis) — shared, fast storage for expensive data.

every layer you can answer from is a database query and a render you did not have to do. the goal is to push as much as possible toward the top of the list.

1. browser caching

the cheapest cache lives in the user's browser. correct Cache-Control headers, hashed asset filenames, and ETags mean repeat visits download almost nothing. i wrote a full breakdown in how browser caching works and why it matters for SEO — and yes, it affects ranking, because it improves core web vitals.

2. cdn / edge caching

a cdn stores your responses in data centers around the world, so a user in singapore is served from singapore, not your origin in virginia. static assets are the obvious win, but you can also cache full html responses at the edge for pages that are the same for everyone. this pairs naturally with the serverless / edge model.

3. incremental static regeneration (ISR)

ISR is next.js's answer to "i want static speed but my content changes." you render a page once, serve the cached html to everyone, and revalidate it on an interval or on demand:

tsx
// revalidate this page at most once an hour
export const revalidate = 3600;

// ...or invalidate instantly when content changes
import { revalidatePath } from "next/cache";
revalidatePath("/notelogs");

choosing between static, ISR, and fully dynamic is exactly the trade-off in SSR vs SSG in Next.js. most content sites should default to static or ISR and only go dynamic where they truly need per-request data.

4. application caching with redis

when a page is dynamic — personalized dashboards, expensive aggregations — you still do not want to hit the database on every request. redis sits between your app and the database as a fast, shared, in-memory store:

ts
async function getDashboard(userId: string) {
  const key = `dashboard:${userId}`;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const data = await buildExpensiveDashboard(userId);
  await redis.set(key, JSON.stringify(data), "EX", 300); // 5-min TTL
  return data;
}

design your data access so caching is easy to bolt on — clean, predictable endpoints help, which is the theme of how to design APIs for Next.js applications.

cache invalidation: the hard part

there are only two hard things in computer science: cache invalidation and naming things.

the failure mode of every cache is serving stale data. two reliable strategies:

• time-based (TTL): let entries expire after N seconds. simple, but users may see slightly old data.
• event-based: explicitly clear the relevant keys/paths when the underlying data changes (e.g. revalidatePath after a publish, or deleting a redis key on update).

most production systems use both: a short TTL as a safety net, plus targeted invalidation on writes for freshness.

putting it together

a typical fast next.js stack layers all four:

• static/ISR pages on a cdn for anonymous traffic
• redis for expensive, shared, dynamic data
• correct browser cache headers on every asset
• event-based invalidation wired into your write paths

the checklist

• [ ] assets have hashed names + long Cache-Control
• [ ] public pages are static or ISR, served via a cdn
• [ ] expensive dynamic data is cached in redis with a sensible TTL
• [ ] writes invalidate the exact paths/keys they affect
• [ ] you have verified freshness, not just speed

related reading

caching is one pillar of a fast site; rendering strategy and shipped-javascript are the others. see SSR vs SSG, React Server Components, and Core Web Vitals in 2026 for the rest of the picture. building something that needs to scale? let's talk.