⚡ API Response Caching Strategies

Why Cache at All?

Every uncached request repeats the same expensive work: query the database, run the computation, serialize the result. If a thousand users ask for the same product page in a minute, an uncached API does that work a thousand times. Caching does it once and hands out copies.

💡 A useful analogy: A busy coffee shop doesn't brew a fresh pot for every customer — it brews a batch and pours from it until it runs low. Caching is that batch: prepare the answer once, serve it quickly to everyone who asks, and only "brew again" when it goes stale.

The payoff is dramatic and compounding:

• Latency drops from hundreds of milliseconds to single digits.
• Server and database load fall, often by an order of magnitude.
• Throughput and resilience rise — you serve traffic spikes on the same hardware, and can keep serving cached data even if the backend hiccups.
• Cost shrinks because you provision for the cache-miss rate, not the total request rate.

Caching Fundamentals

A handful of terms recur throughout every caching system:

The headline metric is the cache hit ratio — the fraction of requests served from cache:

hit ratio = cache hits / total requests

A 95% hit ratio means only one request in twenty reaches your backend. Small improvements here have outsized effects: going from 80% to 95% cuts backend load by three quarters. When a hit ratio is disappointing, the usual culprits are keys that are too specific (so nothing is reused) or TTLs that are too short (so entries expire before they're reused).

HTTP Caching & ETags

Before you build any custom cache, remember that HTTP has caching built in. By sending the right response headers, you let browsers and CDNs cache for you — for free.

Cache-Control

The Cache-Control header is the primary dial. Its directives compose:

// Public, cacheable for a day, revalidate once stale
res.set('Cache-Control', 'public, max-age=86400, must-revalidate');

// Per-user data that must never sit in a shared cache
res.set('Cache-Control', 'private, no-store');

ETags and conditional requests

An ETag is a fingerprint of a response. The client stores it and sends it back in an If-None-Match header; if the resource is unchanged, the server replies 304 Not Modified with an empty body — saving bandwidth even when the client still had to check in.

import crypto from 'node:crypto';

app.get('/api/products/:id', async (req, res) => {
  const product = await getProduct(req.params.id);
  const etag = crypto.createHash('md5')
    .update(JSON.stringify(product))
    .digest('hex');

  // Client already has this exact version?
  if (req.headers['if-none-match'] === etag) {
    return res.status(304).end();
  }

  res.set('ETag', etag);
  res.set('Cache-Control', 'public, max-age=3600');
  res.json(product);
});

Where Caches Live

A request can be answered by a cache at several points along its journey. The earlier a cache intercepts it, the faster and cheaper the response — but the less control you retain.

• Client cache — eliminates the network entirely, but you can't purge it after deployment.
• CDN / proxy — serves millions from the edge, close to users; great for public, non-personalized data.
• API gateway — centralized, can cache authenticated responses with the right keys.
• Application cache (Redis, Memcached) — the most flexible; you control exactly what and when.
• Database cache — query/result caches inside the DB itself.

Core Caching Strategies

Which strategy fits depends on how your data changes.

Time-based (TTL)

The simplest: store the response with an expiry and serve it until the TTL runs out. Perfect for data that's expensive to compute and tolerant of being a little stale — a product catalog, a weather summary, a top-10 list.

Validation-based

Use ETags or Last-Modified so the client keeps its copy until the server confirms a change. Best when accuracy matters and data changes irregularly, and you want to save bandwidth on the (frequent) unchanged case.

Variation-based

Different inputs produce different responses, so the cache key must encode every input that affects the output — query parameters, language, region. Get this wrong and you either miss constantly (keys too fine) or serve the wrong content (keys too coarse).

// The key must capture EVERY input that changes the response
const { page = 1, limit = 10, sort = 'createdAt', category = 'all' } = req.query;
const cacheKey = `products:${category}:${sort}:${page}:${limit}`;

For HTTP-level variation, advertise it with the Vary header so shared caches key correctly:

res.set('Vary', 'Accept-Language');
res.set('Cache-Control', 'public, max-age=600');

The Cache-Aside Pattern

The workhorse of application-level caching is cache-aside (also called lazy loading): check the cache first; on a miss, load from the source and populate the cache for next time.

import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL);

async function getProduct(id) {
  const key = `product:${id}`;

  // 1. Look aside to the cache first
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);        // hit

  // 2. Miss — go to the source of truth
  const product = await db.products.findById(id);

  // 3. Populate the cache for next time (1-hour TTL)
  await redis.set(key, JSON.stringify(product), 'EX', 3600);

  return product;
}

Cache-aside is popular because it's resilient (if the cache is down, requests just fall through to the database) and it only caches data that's actually requested. Its weaknesses are the first-request latency on every miss and the risk of a cache stampede.

Stale-while-revalidate serves the slightly-expired value immediately while refreshing it in the background — the user never waits for the regeneration:

// Serve stale within a grace window, refresh asynchronously
if (age > ttl && age < ttl + gracePeriod) {
  refreshInBackground(key);        // fire-and-forget
  res.set('X-Cache', 'stale');
  return res.json(staleValue);     // instant response
}

Cache Invalidation

"There are only two hard things in Computer Science: cache invalidation and naming things." — Phil Karlton

Invalidation is deciding when a cached entry no longer reflects reality and removing it. There's no single right answer — you pick based on how tolerant your data is of staleness.

The most common combination is TTL as a safety net plus explicit invalidation on writes. When you update a record, delete its cache key so the next read repopulates it, and let the TTL catch anything you forget:

app.put('/api/products/:id', async (req, res) => {
  const product = await db.products.update(req.params.id, req.body);

  // Explicit invalidation: drop the stale entry immediately
  await redis.del(`product:${req.params.id}`);

  res.json(product);
});

Hands-on: Cache a Slow Endpoint

app.get('/api/report/:id', async (req, res) => {
  const report = await buildExpensiveReport(req.params.id); // ~500ms
  res.json(report);
});

app.get('/api/report/:id', async (req, res) => {
  const key = `report:${req.params.id}`;

  const cached = await redis.get(key);
  if (cached) {
    res.set('X-Cache', 'HIT');           // ~2ms
    return res.json(JSON.parse(cached));
  }

  const report = await buildExpensiveReport(req.params.id); // ~500ms
  await redis.set(key, JSON.stringify(report), 'EX', 60);
  res.set('X-Cache', 'MISS');
  res.json(report);
});

app.put('/api/report/:id', async (req, res) => {
  const report = await rebuildReport(req.params.id, req.body);
  await redis.del(`report:${req.params.id}`); // invalidate
  res.json(report);
});

Best Practices

Summary & Quiz

📚 Further Reading

• MDN — HTTP Caching
• RFC 9111 — HTTP Caching
• Redis caching patterns

🚀 What's Next?

We've now hardened, throttled, and accelerated REST APIs. Next we step back to compare architectures entirely: GraphQL vs. REST — how a query language changes the shape of the requests you're caching and securing.