Care sunt straturile cache în stiva web tipică?

Question

Accepted Answer

O cerere trece prin **mai multe straturi cache**, fiecare mai aproape de utilizator servind mai rapid dar având o capacitate mai redusă. Ideea este să răspunzi cât mai departe (aproape de client) posibil și să cazi doar la origine când nimic din stratul superior nu poate servi răspunsul.

## Straturile, de la exterior la interior

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

- **Browser cache** — stochează resurse statice (JS, CSS, imagini) și răspunsuri care pot fi cache-uite pe dispozitivul utilizatorului. TTL-ul este controlat de `Cache-Control`/`ETag`; activele primesc de obicei TTL-uri lungi (zile–an) cu nume de fișiere hash-uite.
- **CDN** (CloudFront, Cloudflare) — cache-uiește conținut static și uneori dinamic la nodurile edge aproape de utilizatori. TTL-uri de la minute (HTML) la un an (active imutabile).
- **Reverse proxy** (Varnish, nginx) — cache-uiește pagini întregi sau fragmente în fața aplicației. TTL-uri de secunde la minute pentru pagini active; suportă ștergerea la schimbare.
- **Cache aplicație / obiect** (Redis, Memcached) — cache-uiește rezultate calculate, rezultate din interogări DB, sesiuni, fragmente de pagini render-uite. TTL-uri de secunde la ore, plus invalidare explicită.
- **OPcache** — cache-uiește **bytecode-ul PHP compilat** în memorie, astfel încât scripturile nu sunt reparse-uite la fiecare cerere. Efectiv persistent până la deploy-ul codului.
- **Cache de interogări DB / buffer cache** — baza de date păstrează pagini active și (în unele motoare) rezultate de interogări în memorie, evitând citiri de disc.

## Cum să gândești despre ele

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

Fiecare strat schimbă **prospețime pentru viteză**: straturile exterioare sunt cele mai rapide dar cel mai probabil stale, deci pune TTL-uri lungi + content hashing pe lucruri cu adevărat statice și TTL-uri scurte + invalidare pe cele dinamice.

## De ce conteaza

Cea mai mare parte a reducerii de latență și încărcare în stiva web provine din cache-uire la stratul corect. Știind ce ține fiecare strat și TTL-ul tipic al acestuia te lasă să plasezi un cache unde chiar ajută, evit să servești date stale, și poți gândi despre de ce o schimbare nu a apărut (care strat servește încă o copie veche).