Jaké jsou vrstvy cache v typickém web stacku?

Question

Accepted Answer

Požadavek prochází **více vrstvami cache**, z nichž každá je blíže uživateli a slouží rychleji, ale obsahuje méně dat. Myšlenka je odpovědět co nejdál (blíže klientu) a pouze se vrátit k původu, když žádná upstream vrstva nemůže odpověď poskytnout.

## Vrstvy, zvenku dovnitř

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

- **Browser cache** — ukládá statické assety (JS, CSS, obrázky) a cacheable odpovědi na zařízení uživatele. TTL je řízen pomocí `Cache-Control`/`ETag`; assety často mají dlouhé TTL (dny–rok) s hasovanými jmény souborů.
- **CDN** (CloudFront, Cloudflare) — cachuje statický a někdy dynamický obsah na edge nodes blízkých uživatelům. TTL od minut (HTML) do roku (immutable assets).
- **Reverse proxy** (Varnish, nginx) — cachuje celé stránky nebo fragmenty před aplikací. TTL od sekund do minut pro horké stránky; podporuje purge při změně.
- **Application / object cache** (Redis, Memcached) — cachuje vypočítané výsledky, výsledky DB dotazů, session, vykreslené fragmenty. TTL od sekund do hodin, plus explicitní invalidace.
- **OPcache** — cachuje **kompilovaný PHP bytecode** v paměti, aby se skripty nezpracovávaly znovu per požadavek. Efektivně trvalý až do nasazení kódu.
- **DB query / buffer cache** — databáze uchovává horké stránky a (v některých enginech) výsledky dotazů v paměti, což se vyhne čtení z disku.

## Jak o nich uvažovat

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

Každá vrstva si vyměňuje **čerstvost za rychlost**: vnější vrstvy jsou nejrychlejší, ale nejspíš zastaralé, takže umisťujte dlouhé TTL + hashing obsahu na skutečně statické věci a krátké TTL + invalidaci na dynamické.

## Proč na tom záleží

Většina latence a snížení zátěže ve web stacku pochází z cachování na správné vrstvě. Vědět, co jednotlivá vrstva drží a jaké má typické TTL, vám umožní umístit cache tam, kde skutečně pomáhá, vyhnout se podávání zastaralých dat a zdůvodnit, proč se změna nezobrazila (která vrstva stále poskytuje starou kopii).