Skip to content
Tech Interview Prep home
Technical interview guide

Caching Strategies

Production caching for technical interviews: placement, read/write patterns, freshness, stampedes, HTTP caching, observability, failure recovery, and decision tradeoffs.

Read
24 min
Practice MCQs
25
Interview QA
25
Edition
v4
Editorial status
Reviewed

Scope: HTTP caching per RFC 9111 and RFC 5861; Redis behavior referenced from current official documentation accessed 2026-08-30..

Interview QA

Treat each question like a live interview question: answer out loud first (structure, assumptions, tradeoffs), then open the model answer to spot gaps and rehearse a tighter follow-up.

Curated: · Written: · Reviewed:

QA-1

Explain the cache-aside pattern and one downside of it.

QA-2

Explain write-behind (write-back) caching and the risk-vs-performance tradeoff it makes compared to write-through.

QA-3

One cache key for a viral item absorbs 40% of your read traffic and saturates the single shard it hashes to — how would you fix it without giving up caching?

QA-4

How would you decide between LRU and LFU eviction policies for a specific caching workload?

QA-5

How does a cache stampede happen, and what's one way to mitigate it?

QA-6

Explain the cold-cache problem after a cache server restart, and how cache warming addresses it.

QA-7

When would write-through caching be preferred over cache-aside?

QA-8

How would you design a multi-level caching architecture for a high-traffic web application, and what role does each level play?

QA-9

Why does caching a computed aggregate (like "total sales this month") require more careful invalidation logic than caching a single raw record?

QA-10

How would you measure and improve a poor cache hit ratio for a specific application?

QA-11

Explain why a distributed cache is generally required (rather than a local in-process cache) once an application scales to multiple server instances behind a load balancer.

QA-12

How would you mitigate the risk of losing recent writes in a write-behind caching system, without fully reverting to write-through's synchronous latency cost?

QA-13

Why might TTL-based expiration alone be insufficient for data that needs to reflect changes immediately, and how would you combine TTL with explicit invalidation?

QA-14

How would you decide what granularity to cache at — e.g. caching an entire rendered page, versus caching individual data fragments that get assembled into a page?

QA-15

How would you use HTTP caching headers (Cache-Control, ETag) to let browsers and CDNs cache API responses appropriately?

QA-16

Explain why caching negative results (e.g. "this user ID doesn't exist") can be just as important as caching positive results for protecting a backend from load.

QA-17

How would you design a cache key scheme to avoid accidentally serving one user's cached data to a different user?

QA-18

Explain why a cache with a very short TTL might provide little real performance benefit despite technically "caching" data.

QA-19

How would you handle caching for a value that's expensive to compute but changes on an unpredictable schedule (not a fixed TTL, but triggered by specific events)?

QA-20

Why might caching database query results at the application layer sometimes be redundant with a database's own internal query result caching?

QA-21

How would you decide whether to cache at the API gateway/edge layer versus deep within a specific microservice?

QA-22

Explain the risk of caching data that includes sensitive or user-specific information at a shared layer like a CDN, and how Cache-Control headers help prevent this.

QA-23

How would you approach debugging a production issue where users report seeing stale data intermittently, given multiple caching layers might be involved (browser cache, CDN, application cache, database)?

QA-24

Why might a caching strategy that works well for a monolithic application need to be redesigned when that application is split into microservices?

QA-25

How would you implement event-driven cache invalidation for a product catalog, where a product update should immediately invalidate its cached entry across all application instances?