Caching Strategies

Caching stores a result so future reads can skip expensive work. It can reduce latency, database load, and infrastructure cost. It can also serve stale or incorrect data if keys and invalidation are careless.

Cache Keys

A cache key must include every input that changes the result.

function projectListCacheKey(userId: string, status: "open" | "archived", page: number) {
  return `projects:${userId}:${status}:${page}`;
}

If the key omits userId, one user may see another user’s projects. If it omits status, archived and open projects may mix.

Expiration and Invalidation

async function getProjectSummary(projectId: string) {
  const key = `project-summary:${projectId}`;
  const cached = await cache.get<ProjectSummary>(key);
  if (cached) return cached;

  const summary = await buildProjectSummary(projectId);
  await cache.set(key, summary, { ttlSeconds: 300 });
  return summary;
}

Time-to-live expiration is simple and robust for data that can be a little stale. For user-facing writes, invalidate or update the cache immediately after the write succeeds.

NOTE

Caching is a correctness problem before it is a performance problem. Know how stale each response is allowed to be.

HTTP Caching

Public assets and anonymous API responses can use Cache-Control, ETag, and CDN caches. Private account data should be marked private or not cached by shared infrastructure.

WARNING

Never put personalized data behind a shared public cache unless the cache key varies by the authenticated user in a proven way.

Further Learning

Search these terms to go deeper:

“cache aside pattern” — common application caching strategy
“HTTP Cache-Control ETag explained” — browser and CDN caching
“Redis caching patterns” — in-memory cache usage
“cache invalidation strategies” — keeping cached data correct

Caching Strategies

Caching means saving the answer to an expensive question so you don’t have to work it out again next time. It can make your backend dramatically faster — but get it wrong and you’ll serve stale (or even the wrong person’s!) data.

The cache key must include everything that matters

A cache key is the “label” you save a result under. If your key is missing something important, you’ll accidentally show the wrong data:

function cacheKey(userId, status, page) {
  return `projects:${userId}:${status}:${page}`
}

IMPORTANT

If the key left out userId, one user could see another user’s cached data! Always include every input that changes the result in the key.

How long to keep it

Give cached data an expiry time based on how “fresh” it needs to be:

const cached = await cache.get(key)
if (cached) return cached

const fresh = await computeExpensiveThing()
await cache.set(key, fresh, { ttlSeconds: 300 })  // good for 5 minutes
return fresh

For anything the user just changed (like their own profile), update or clear the cache immediately after the write — don’t wait for the expiry.

In one sentence

Caching saves expensive results under a key — make sure the key includes every input that affects the answer (or you’ll leak data between users), give it a sensible expiry, and clear it right after a write that changes it.

Want to go deeper?

Switch to Expert mode above for HTTP caching (Cache-Control, ETag) and cache invalidation patterns.