Caching and Performance Engineering · Caching Fundamentals
The Caching Layers of a Web System
Browser, CDN, reverse proxy, application and database caches — and what belongs where.
Caching happens at many layers: the browser (HTTP cache, service workers), the CDN/edge (static assets, public pages, API responses), reverse proxies (Varnish, Nginx), the application (in-process memory, Redis/Memcached), and the database (buffer pool, materialized views). The closer to the user, the bigger the latency win — but the harder invalidation becomes. Decide per data type: how fresh must it be, is it public or per-user, and what does a miss cost?
Data | Layer | Freshness
-----------------------------|-------------------------------|-----------------------------
app.3f9a2c.js, fonts, images | Browser + CDN (immutable) | forever (content-hashed URL)
Product page (public) | CDN, s-maxage=60, SWR | ≤ 1 minute
Product prices | Redis, TTL 30s + invalidation | seconds
User's cart | Redis per user / DB | always fresh, never shared
Analytics dashboard | Materialized view, hourly | 1 hour
Common pitfalls
- Caching personalized responses in shared caches.
- Caching everything everywhere with no invalidation plan.
- Ignoring the cost of cold caches after deploys or failovers.
Key points
- Cache closest to the user that correctness allows
- Decide freshness per data type
- Public vs private data determines the layer
Further reading: MDN: HTTP caching
Practice questions
Why can static assets be cached 'forever' safely?
Answer
When filenames include a content hash, any change produces a new URL, so old cached files are never served for new code.
What questions decide where a piece of data should be cached?
Answer
How fresh it must be, whether it's public or user-specific, how expensive a miss is, how often it's read vs written, and how invalidation will work.
Open in the app to mark lessons complete, take notes and track your progress.