Quali sono i livelli di cache in uno stack web tipico?

Question

Accepted Answer

Una richiesta attraversa **molteplici livelli di cache**, ognuno più vicino all'utente e quindi più veloce ma con minore capacità. L'idea è rispondere il più lontano possibile (vicino al client) e ricadere nell'origine solo quando nessuno dei livelli upstream può servire la risposta.

## I livelli, dall'esterno all'interno

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

- **Browser cache** — memorizza asset statici (JS, CSS, immagini) e risposte cacheable nel dispositivo dell'utente. Il TTL è controllato da `Cache-Control`/`ETag`; gli asset spesso hanno TTL lunghi (giorni–anno) con nomi di file con hash.
- **CDN** (CloudFront, Cloudflare) — cache contenuti statici e talvolta dinamici nei nodi edge vicini agli utenti. TTL da minuti (HTML) a un anno (asset immutabili).
- **Reverse proxy** (Varnish, nginx) — cache pagine intere o frammenti davanti all'app. TTL di secondi a minuti per pagine hot; supporta purge al cambiamento.
- **Application / object cache** (Redis, Memcached) — cache risultati computati, risultati query DB, sessioni, frammenti renderizzati. TTL da secondi a ore, più invalidazione esplicita.
- **OPcache** — cache **bytecode PHP compilato** in memoria in modo che gli script non vengano ri-parsati per ogni richiesta. Effettivamente persistente fino al deploy del codice.
- **DB query / buffer cache** — il database mantiene pagine hot e (in alcuni engine) risultati query in memoria, evitando letture da disco.

## Come ragionarci

```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
```

Ogni livello scambia **freschezza per velocità**: i livelli esterni sono più veloci ma più probabilmente stantii, quindi metti TTL lunghi + content hashing su cose veramente statiche e TTL brevi + invalidazione su quelle dinamiche.

## Perché è importante

La maggior parte della riduzione di latenza e carico in uno stack web proviene dal caching al livello giusto. Sapere cosa ogni livello tiene e il suo TTL tipico ti permette di posizionare una cache dove effettivamente aiuta, evitare di servire dati stantii, e ragionare su perché un cambio non è apparso (quale livello sta ancora servendo una copia vecchia).