What is caching and where does it fit in a typical system architecture?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
A cache is a fast, small storage layer that stores copies of expensive-to-compute or slow-to-fetch data so future requests serve faster. Place it between your app and the data source (browser cache → CDN → reverse proxy cache → app cache → database cache). The closer to the user, the bigger the latency win and the less origin load.
Detailed explanation
Caching exploits temporal locality — data requested once is likely requested again soon. Layers, from user inward: (1) Browser cache (Cache-Control, ETag) avoids the network entirely. (2) CDN caches static and even dynamic content at edge PoPs close to users. (3) Reverse-proxy / edge cache (Varnish, NGINX, Cloudflare Workers) serves full pages or API responses before hitting your origin. (4) Application cache (in-process or external like Redis/Memcached) stores computed results, session data, or hot database rows. (5) Database cache (query cache, buffer pool) is managed by the DB itself. Cache patterns: cache-aside (app checks cache, falls back to DB, writes to cache) is the workhorse; write-through (writes go to cache and DB together) keeps cache fresh but adds write latency; write-behind (writes go to cache, async to DB) is fastest but risks data loss. Expiration strategies: TTL (time-to-live), LRU/LFU eviction when the cache is full, and explicit invalidation when source data changes. The hard part is cache invalidation — staleness versus freshness. Biggest pitfalls: thundering herd (cache expiry triggers a flood of DB reads — mitigate with request coalescing or early recomputation), cold starts, and caching user-specific data without proper key namespacing. Measure hit ratio; a good cache layer often exceeds 90%.
Example
Request flow with cache:
1. Browser checks local cache → HIT → done (0 ms)
2. MISS → CDN edge checks → HIT → serve (10 ms)
3. MISS → reverse proxy (Varnish) checks → HIT (12 ms)
4. MISS → app checks Redis for product:123 → HIT (14 ms)
5. MISS → app queries DB, stores result in Redis with TTL 300s (80 ms)Interview tip
Walk the layers from browser inward and name a technology for each. Then land on cache invalidation as the hardest part and mention TTL plus cache-aside. That layered answer plus the invalidation caveat is what senior candidates give.
Common mistakes
- Describing only one cache layer instead of the full stack.
- Not mentioning cache invalidation or staleness.
- Forgetting thundering herd when a hot key expires.