Caching
Caching stores the result of a computation or request close to where it will be used so identical future requests can reuse it. On the web, caches exist at the browser, CDN edge, reverse proxy, application, and database layers — making it the highest-leverage performance optimization available.
How it works
Caching trades possible staleness for nearly free access, so every caching problem reduces to two questions: what to cache (Cache Key design) and when to invalidate (TTL and purge strategy). Work through the layers: browser caches follow response headers like Cache-Control; CDN caches follow cache rules and origin-fetch policy; application caches (Redis and friends) absorb database queries; the database's buffer pool absorbs disk access. The classic failure modes are a sudden hit-ratio drop and a cache avalanche where many keys expire at once and crush the database — mitigations include jittered expiry times, hot keys that never expire with background refresh, and hit-ratio monitoring with alerts. For the CDN layer specifically, see our article on lifting CDN cache hit ratios from 60% to 95%.
Examples
- 1.Fingerprinted static assets cached for a year, refreshed on every deploy
- 2.Hot article pages cached in Redis, cutting database queries by an order of magnitude
- 3.Tuning CDN cache rules lifts the hit ratio from 60% to 95%