What are the cache layers in a typical web stack?

Question

Accepted Answer

A request passes through **multiple cache layers**, each closer to the user serving faster but holding less. The idea is to answer as far out (close to the client) as possible and only fall through to the origin when nothing upstream can serve the response.

## The layers, outward-in

```text
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest)                            (closest to data)
```

- **Browser cache** — stores static assets (JS, CSS, images) and cacheable responses on the user's device. TTL is controlled by `Cache-Control`/`ETag`; assets often get long TTLs (days–year) with hashed filenames.
- **CDN** (CloudFront, Cloudflare) — caches static and sometimes dynamic content at edge nodes near users. TTLs from minutes (HTML) to a year (immutable assets).
- **Reverse proxy** (Varnish, nginx) — caches full pages or fragments in front of the app. TTLs of seconds to minutes for hot pages; supports purge on change.
- **Application / object cache** (Redis, Memcached) — caches computed results, DB query results, sessions, rendered fragments. TTLs of seconds to hours, plus explicit invalidation.
- **OPcache** — caches **compiled PHP bytecode** in memory so scripts aren't re-parsed per request. Effectively persistent until code deploys.
- **DB query / buffer cache** — the database keeps hot pages and (in some engines) query results in memory, avoiding disk reads.

## How to reason about them

```text
for each layer outward → inward:
  if layer has fresh copy → return it (stop here)   // a hit; cheapest possible
  else → ask the next layer in                      // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
```

Each layer trades **freshness for speed**: outer layers are fastest but most likely stale, so put long TTLs + content hashing on truly static things and short TTLs + invalidation on dynamic ones.

## Why it matters

Most latency and load reduction in a web stack comes from caching at the right layer. Knowing what each layer holds and its typical TTL lets you place a cache where it actually helps, avoid serving stale data, and reason about why a change didn't appear (which layer is still serving an old copy).