What is the difference between no-cache and no-store?

no-cache means the browser may store the response but must revalidate with the server before using it (conditional request with ETag or Last-Modified). no-store means do not store the response anywhere — used for sensitive data like banking or health records.

When should you use cache-first vs network-first?

Cache-first: static assets (CSS, JS, images) that rarely change — serve from cache, fetch only on miss. Network-first: dynamic API data or user-specific content — try network, fall back to cache when offline.

What is stale-while-revalidate?

Return cached data immediately (even if stale), then fetch fresh data in the background and update the cache. Users get instant responses while data stays reasonably fresh — ideal for blog posts, product catalogs, and news feeds.

Should you cache POST requests?

Generally no. POST mutates server state and responses are often not idempotent. Cache GET requests by default. Only cache POST if explicitly designed for it (rare) and with careful invalidation.

Caching Strategies

Browser, CDN, Redis, Service Workers, and client-side API caching — every layer SDE-2 interviews cover.

Module 5 · Caching Strategies

Multi-layer caching from browser to database: HTTP headers, CDN, Redis, cache patterns (cache-first, stale-while-revalidate), browser storage APIs, and React Query / SWR client caching.

Multi-layer caching from browser HTTP cache to CDN, application Redis, and database query cache — plus cache-first, network-first, stale-while-revalidate patterns, browser storage APIs, and React Query / SWR client caching.

About this module

Caching is one of the highest-leverage frontend performance techniques — it reduces load times, server load, and improves scalability across every layer of the stack.

This module covers the four caching layers, six core cache strategies, browser storage options, API caching with TanStack Query and SWR, and the best practices SDE-2 interviews expect.

You will understand cache invalidation trade-offs, when stale-while-revalidate beats cache-first, how CDN edge caching interacts with Cache-Control headers, and how to avoid serving stale or sensitive data to the wrong user.

Layers covered: browser HTTP cache, CDN, application cache (Redis), database query cache, Service Worker strategies, and client libraries like TanStack Query — each with headers, patterns, and interview comparisons.

Why this matters

Every SDE-2 frontend interview touches caching: Cache-Control headers, CDN edge caching, Service Worker strategies, and client-side data libraries. Wrong cache policy means stale data, security leaks, or slow pages. Knowing when to invalidate vs serve stale data is as important as knowing how to cache.

Key topics covered

Browser HTTP Caching
CDN Caching
Application-Level Caching
Database Caching
Cache-First Pattern
Network-First Pattern
Stale-While-Revalidate
Cache Busting
Browser Storage APIs
React Query
SWR
Caching Best Practices

Where you'll use it

Setting Cache-Control for static assets vs HTML pages
Implementing stale-while-revalidate in a Service Worker
Choosing between LocalStorage, IndexedDB, and Cache API
Configuring TanStack Query staleTime and gcTime for API data
Invalidating CDN cache after a deployment without stale user sessions

What Is Caching?

Store copies of data closer to the user for faster access — SDE-2 frontend essential.

Caching stores copies of files or data in temporary storage so they can be accessed more quickly on subsequent requests. Every layer of the stack — browser, CDN, application server, database — can cache.

Interactive · Cache layer flow

Browser cache

—

CDN edge

—

App server

—

Database

—

•Reduces load times — faster responses from cache hits
•Decreases origin server load and cost
•Improves scalability under traffic spikes
•Better UX on slow or unreliable networks
•Enables offline experiences when paired with Service Workers

Multi-Layer Caching Strategy

Four layers — each closer to the user means lower latency.

1Browser Cache

HTTP cache for HTML, CSS, JS, images, API responses

2CDN Cache

Edge servers worldwide — static assets and cacheable HTML/API

3Application Cache

Redis / Memcached — rendered pages, fragments, computed data

4Database Cache

Query result cache, indexes — reduces DB round-trips

Interview framing

A request hits the browser cache first, then CDN, then application cache, then database — only reaching the origin on a full cache miss. Each layer has different TTLs and invalidation rules.

Layer 1: Browser HTTP Caching

Cache-Control, ETag, and Last-Modified — the headers that control client-side caching.

# Static assets (images, CSS, JS) — cache 1 year
Cache-Control: public, max-age=31536000

# HTML pages — revalidate every time
Cache-Control: no-cache

# Sensitive data — never store
Cache-Control: private, no-store

# Validate with ETag
ETag: "abc123"
Last-Modified: Wed, 21 Oct 2026 07:28:00 GMT

Header	Value	Behavior
Cache-Control	max-age=3600	Cache for 3600 seconds (1 hour)
Cache-Control	no-cache	Store but revalidate before using
Cache-Control	no-store	Do not cache at all
Expires	2026-12-31 23:59:59 GMT	Hard expiration date/time
ETag	"abc123"	Version identifier for conditional requests
Last-Modified	Wed, 21 Oct 2026 ...	Resource last modified time

no-cache vs no-store

no-cache = may store, must revalidate before use. no-store = never store anywhere. Use no-store for auth tokens, payment data, and PII.

Layer 2: CDN Caching

Geographically distributed edge caches — lower latency, higher throughput.

CDNs store copies of static assets and cacheable responses at edge locations close to users. The browser talks to the nearest edge node instead of your origin server — cutting round-trip time and absorbing traffic spikes.

•Geographically distributed — lower latency worldwide
•Reduces origin server load and bandwidth cost
•Handles traffic spikes (DDoS mitigation, viral traffic)
•Popular CDNs: Cloudflare, AWS CloudFront, Fastly, Akamai

Layer 3: Application-Level Caching

Redis and Memcached — page, fragment, and data caching at the server.

•Page caching — entire rendered HTML responses
•Fragment / component caching — sidebars, widgets, nav
•Data caching — expensive computations, API aggregation results

// Redis cache-aside pattern
const user = await redis.get("user:123");
if (!user) {
  const fresh = await db.query("SELECT * FROM users WHERE id = 123");
  await redis.set("user:123", JSON.stringify(fresh), { EX: 3600 });
  return fresh;
}
return JSON.parse(user);

Layer 4: Database Caching

Query result cache and indexes — reduce expensive DB reads.

•Query caching — MySQL / PostgreSQL built-in (where enabled)
•Object caching — Redis / Memcached in front of DB
•Indexing — B-tree indexes act as automatic lookup cache

-- Indexing (automatic lookup optimization)
CREATE INDEX idx_user_email ON users(email);

-- Check query cache settings (MySQL)
SHOW VARIABLES LIKE "query_cache%";

Cache Strategy Patterns

Six patterns — pick based on freshness requirements and offline needs.

1. Cache First (Cache-Then-Network)

Use case: Static assets (images, CSS, JS) that rarely change

async function cacheFirst(url) {
  const cached = await caches.match(url);
  if (cached) return cached;

  const response = await fetch(url);
  const cache = await caches.open("my-cache");
  cache.put(url, response.clone());
  return response;
}

2. Network First (Network-Then-Cache)

Use case: Dynamic content — API responses, user-specific data

async function networkFirst(url) {
  try {
    const response = await fetch(url);
    const cache = await caches.open("my-cache");
    cache.put(url, response.clone());
    return response;
  } catch {
    const cached = await caches.match(url);
    return cached ?? new Response("Offline", { status: 503 });
  }
}

3. Stale-While-Revalidate

Use case: Content tolerating slight staleness — blog posts, news, catalogs

async function staleWhileRevalidate(url) {
  const cached = await caches.match(url);

  // Refresh in background
  fetch(url).then(async (response) => {
    const cache = await caches.open("my-cache");
    cache.put(url, response.clone());
  });

  return cached ?? fetch(url);
}

4. Time-Based Expiration (TTL)

Use case: Session data, user preferences, API responses with known freshness window

const store = {};

function getWithTTL(key, ttlMs = 3_600_000) {
  const entry = store[key];
  if (entry && Date.now() - entry.timestamp < ttlMs) {
    return entry.data;
  }
  const data = fetchFromDatabase(key);
  store[key] = { data, timestamp: Date.now() };
  return data;
}

5. Write-Through Caching

Use case: Data needing consistency — user profiles, inventory counts

async function writeThrough(key, value) {
  await cache.set(key, value);
  await db.save(key, value);
}

6. Cache Busting

Use case: API responses or data structures that change shape

const version = "v1";
const key = `${version}:product:123`;

// On schema change, bump version
const newKey = "v2:product:123";
await cache.set(newKey, newValue);

Browser Storage Options

Cache API, IndexedDB, LocalStorage, SessionStorage, and Cookies.

Storage	Capacity	Sync/Async	Use Case	Lifetime
Cache API	Large (quota-based)	Async	Service Worker network cache	Persistent
IndexedDB	~50–100 MB+	Async	Large structured data, offline apps	Persistent
LocalStorage	~5 MB	Sync	Small key-value, user preferences	Persistent
SessionStorage	~5 MB	Sync	Temporary form state, tab-scoped data	Session only
Cookies	~4 KB	Sync	Auth tokens, session IDs	Expiration-based

// Cache API (Service Workers)
const cache = await caches.open("v1");
await cache.add("/api/products");
const response = await cache.match(request);
await caches.delete("v1");

// IndexedDB (large structured data)
const db = await openDB("my-db", 1, {
  upgrade(db) {
    db.createObjectStore("products", { keyPath: "id" });
  },
});
await db.put("products", { id: 1, name: "Product" });
const product = await db.get("products", 1);

// LocalStorage (simple sync KV)
localStorage.setItem("user", JSON.stringify({ id: 1, name: "John" }));
const user = JSON.parse(localStorage.getItem("user") ?? "null");

When to use which

Service Worker network caching → Cache API. Offline app with large datasets → IndexedDB. Theme preference or small flags → LocalStorage. Never store auth tokens in LocalStorage (XSS risk) — use httpOnly cookies instead.

API Caching — React Query & SWR

Client-side in-memory caching with background revalidation.

TanStack Query (React Query)

import { useQuery } from "@tanstack/react-query";

const { data, isLoading, isError } = useQuery({
  queryKey: ["users"],
  queryFn: fetchUsers,
  staleTime: 5 * 60 * 1000,  // 5 min — data considered fresh
  gcTime: 30 * 60 * 1000,    // 30 min — keep in cache after unmount
  retry: 3,
});

•In-memory cache keyed by queryKey
•Background revalidation when stale
•Automatic request deduplication
•Pagination and infinite query support

SWR

import useSWR from "swr";

function Profile() {
  const { data, error } = useSWR("/api/user", fetcher, {
    refreshInterval: 5000,    // poll every 5s
    dedupingInterval: 2000,   // dedupe requests within 2s
  });
}

•Lightweight — minimal API surface
•Built-in cache with stale-while-revalidate behavior
•Polling and focus revalidation support

Caching Best Practices

What to cache, what to avoid, and how to invalidate correctly.

✅ Do	Why
Cache only GET requests	POST mutates state — responses should be fresh
Set reasonable TTLs	1 hour for API, 1 year for hashed static assets
Monitor hit/miss rates	Tune policies based on real data
Use cache versioning	v1:product:123 → v2:product:123 on schema change
Document what's cached	Where, why, TTL — for team clarity

❌ Don't	Problem
Cache POST without design	Data inconsistency, wrong mutations
Infinite TTL on dynamic data	Stale data forever
Cache user data globally on CDN	Security risk — wrong user sees data
Skip cache invalidation	Stale data persists after updates
Over-cache everything	Memory waste, harder debugging

Sensitive data rule

Never cache auth tokens, payment info, or user-specific PII in shared caches (CDN, public Redis keys). Use Cache-Control: private, no-store and httpOnly cookies for session management.

Frequently Asked Questions

Common interview questions about caching strategies.

# Static assets (images, CSS, JS) — cache 1 year Cache-Control: public, max-age=31536000 # HTML pages — revalidate every time Cache-Control: no-cache # Sensitive data — never store Cache-Control: private, no-store # Validate with ETag ETag: "abc123" Last-Modified: Wed, 21 Oct 2026 07:28:00 GMT

Header

Value

Behavior

Cache-Control

max-age=3600

Cache for 3600 seconds (1 hour)

Cache-Control

no-cache

Store but revalidate before using

Cache-Control

no-store

Do not cache at all

Expires

2026-12-31 23:59:59 GMT

Hard expiration date/time

ETag

"abc123"

Version identifier for conditional requests

Last-Modified

Wed, 21 Oct 2026 ...

Resource last modified time

// Redis cache-aside pattern const user = await redis.get("user:123"); if (!user) { const fresh = await db.query("SELECT * FROM users WHERE id = 123"); await redis.set("user:123", JSON.stringify(fresh), { EX: 3600 }); return fresh; } return JSON.parse(user);

async function cacheFirst(url) { const cached = await caches.match(url); if (cached) return cached; const response = await fetch(url); const cache = await caches.open("my-cache"); cache.put(url, response.clone()); return response; }

async function networkFirst(url) { try { const response = await fetch(url); const cache = await caches.open("my-cache"); cache.put(url, response.clone()); return response; } catch { const cached = await caches.match(url); return cached ?? new Response("Offline", { status: 503 }); } }

async function staleWhileRevalidate(url) { const cached = await caches.match(url); // Refresh in background fetch(url).then(async (response) => { const cache = await caches.open("my-cache"); cache.put(url, response.clone()); }); return cached ?? fetch(url); }

Storage

Capacity

Sync/Async

Use Case

Lifetime

Cache API

Large (quota-based)

Async

Service Worker network cache

Persistent

IndexedDB

~50–100 MB+

Async

Large structured data, offline apps

Persistent

LocalStorage

~5 MB

Sync

Small key-value, user preferences

Persistent

SessionStorage

~5 MB

Sync

Temporary form state, tab-scoped data

Session only

~4 KB

Sync

Auth tokens, session IDs

Expiration-based

// Cache API (Service Workers) const cache = await caches.open("v1"); await cache.add("/api/products"); const response = await cache.match(request); await caches.delete("v1"); // IndexedDB (large structured data) const db = await openDB("my-db", 1, { upgrade(db) { db.createObjectStore("products", { keyPath: "id" }); }, }); await db.put("products", { id: 1, name: "Product" }); const product = await db.get("products", 1); // LocalStorage (simple sync KV) localStorage.setItem("user", JSON.stringify({ id: 1, name: "John" })); const user = JSON.parse(localStorage.getItem("user") ?? "null");

import { useQuery } from "@tanstack/react-query"; const { data, isLoading, isError } = useQuery({ queryKey: ["users"], queryFn: fetchUsers, staleTime: 5 * 60 * 1000, // 5 min — data considered fresh gcTime: 30 * 60 * 1000, // 30 min — keep in cache after unmount retry: 3, });

import useSWR from "swr"; function Profile() { const { data, error } = useSWR("/api/user", fetcher, { refreshInterval: 5000, // poll every 5s dedupingInterval: 2000, // dedupe requests within 2s }); }

✅ Do

Why

Cache only GET requests

POST mutates state — responses should be fresh

Set reasonable TTLs

1 hour for API, 1 year for hashed static assets

Monitor hit/miss rates

Tune policies based on real data

Use cache versioning

v1:product:123 → v2:product:123 on schema change

Document what's cached

Where, why, TTL — for team clarity

❌ Don't

Problem

Cache POST without design

Data inconsistency, wrong mutations

Infinite TTL on dynamic data

Stale data forever

Cache user data globally on CDN

Security risk — wrong user sees data

Skip cache invalidation

Stale data persists after updates

Over-cache everything

Memory waste, harder debugging

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

What Is Caching?

Multi-Layer Caching Strategy

Layer 1: Browser HTTP Caching

Layer 2: CDN Caching

Layer 3: Application-Level Caching

Layer 4: Database Caching

Cache Strategy Patterns

Browser Storage Options

API Caching — React Query & SWR

Caching Best Practices

Frequently Asked Questions

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

What Is Caching?

Multi-Layer Caching Strategy

Layer 1: Browser HTTP Caching

Layer 2: CDN Caching

Layer 3: Application-Level Caching

Layer 4: Database Caching

Cache Strategy Patterns

Browser Storage Options

API Caching — React Query & SWR

Caching Best Practices

Frequently Asked Questions