Wat zijn de cache-lagen in een typische webstack?

Question

Accepted Answer

Een verzoek passeert **meerdere cache-lagen**, elk dichter bij de gebruiker en sneller maar met minder capaciteit. Het idee is om zo dicht mogelijk bij de client een antwoord te geven en alleen terug te vallen op de oorsprong als geen upstream-cache het antwoord kan serveren.

## De lagen, van buiten naar binnen

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

- **Browser cache** — slaat statische assets (JS, CSS, afbeeldingen) en cacheable responses op het apparaat van de gebruiker op. TTL wordt bepaald door `Cache-Control`/`ETag`; assets krijgen vaak lange TTLs (dagen tot jaar) met gehashte bestandsnamen.
- **CDN** (CloudFront, Cloudflare) — cacht statische en soms dynamische content op edge nodes dicht bij gebruikers. TTLs variëren van minuten (HTML) tot een jaar (immutable assets).
- **Reverse proxy** (Varnish, nginx) — cacht volledige pagina's of fragmenten voor de app. TTLs van seconden tot minuten voor populaire pagina's; ondersteunt invalidatie bij wijzigingen.
- **Application / object cache** (Redis, Memcached) — cacht berekende resultaten, databasequery-resultaten, sessies, gerenderde fragmenten. TTLs van seconden tot uren, plus expliciete invalidatie.
- **OPcache** — cacht **gecompileerde PHP bytecode** in het geheugen zodat scripts niet per verzoek opnieuw geparseerd worden. Effectief persistent tot code wordt uitgerold.
- **DB query / buffer cache** — de database houdt populaire pagina's en (in sommige engines) query-resultaten in het geheugen, waardoor schijflezen wordt vermeden.

## Hoe erover na te denken

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

Elke laag verhandelt **versheid voor snelheid**: buitenlaagse lagen zijn snelst maar waarschijnlijker verouderd, dus plaats lange TTLs + content hashing op echt statische dingen en korte TTLs + invalidatie op dynamische.

## Waarom het belangrijk is

De meeste latentie- en belastingvermindering in een webstack komt uit caching op de juiste laag. Weten wat elke laag bevat en de typische TTL stelt je in staat een cache daar te plaatsen waar het werkelijk helpt, vermijd het serveren van verouderde data, en redeneer erachter waarom een wijziging niet zichtbaar werd (welke laag serveert nog steeds een oude kopie).