Caching Strategies Interview Questions and Answers

Caching stores a copy of data in a faster or closer tier so future reads avoid the slower origin. It reduces latency, increases throughput, lowers load and cost on databases and external APIs, and improves availability during partial outages.

Common tiers: in-process memory (fastest, per instance), a shared cache such as Redis or Memcached, a CDN at the edge, and HTTP browser caches.

The costs are staleness, extra moving parts and consistency work. A cache is a copy, so you must decide acceptable staleness, an invalidation strategy, what to store, and what happens when the cache is empty or unavailable.

client -> CDN -> app cache (Redis) -> database

The key questions are always: what is the cache key, how long may data be stale, how is it invalidated, and can the system serve correctly when the cache fails? Caching is not free performance; it trades consistency and complexity for speed.

Cache-aside (lazy loading): the application checks the cache first. On a miss it reads the database, then writes the value into the cache and returns it. The application owns all cache interaction.

let v = await cache.get(key);
if (!v) {
  v = await db.get(key);
  await cache.set(key, v, ttl);
}
return v;

Read-through: the application always asks the cache, and the cache itself knows how to load from the origin on a miss. It is simpler for callers and often provided by a library or proxy, but hides the latency and error behavior of the loader.

Both leave the write path separate, so they are usually paired with a write policy. Cache-aside is the most common and most flexible, at the cost of duplicated loading logic and more code paths to maintain. Read-through centralizes loading but requires cache support for it and can mask backend problems.

A content delivery network caches content on edge servers close to users. It serves static assets such as images, CSS, JavaScript and fonts, and can cache dynamic responses and API responses when headers permit.

Benefits: lower latency from geographic proximity, offloaded origin traffic, absorption of traffic spikes and DDoS mitigation, plus TLS termination at the edge.

Cache-Control: public, max-age=31536000, immutable
Cache-Control: s-maxage=60, stale-while-revalidate=30

Control behavior with Cache-Control (max-age for browsers, s-maxage for shared caches, private, no-store), ETag for revalidation, and Vary to prevent serving one user's response to another. Invalidate by purging URLs or using surrogate keys. A crucial warning: never cache authenticated or personalized responses in a shared cache unless the cache key includes the identity, or you will leak data across users.