What is caching and where to cache

Caching stores a copy of data in a faster or closer store so repeated requests can be served without recomputing or hitting the primary source (DB, API). It reduces latency and load on the source.

Request path: where caches sit

flowchart LR C[Client] --> Browser[Browser cache] Browser --> CDN[CDN / Edge] CDN --> App[App server cache] App --> Cache[Redis/Memcached] Cache --> DB[(Database)]

Cache layers

Layer	Where	Typical use
Browser	Client	Static assets, HTTP cache headers
CDN / Edge	Edge POPs	Static files, API response cache
Application	In-process or local	Hot data, computed results
Distributed cache	Redis, Memcached	Shared cache across app servers
DB layer	Query cache, buffer pool	DB’s own optimization

What to cache

flowchart TB subgraph Good["Good to cache"] G1[Read-heavy, rarely changing] G2[Expensive to compute] G3[Static or semi-static assets] end subgraph Bad["Avoid or short TTL"] B1[User-specific, sensitive] B2[Frequently updated] B3[Must be real-time] end

Cache where it gives the most benefit: close to the client for latency (CDN, browser), close to the app for throughput (Redis). Invalidate or set TTL when data can change.