En request passerer gennem flere cache-lag, hvor hvert lag er tættere på brugeren og serverer hurtigere, men holder mindre data. Ideen er at besvare så langt ude (tæt på klienten) som muligt og kun falde tilbage til origin, når intet upstream kan servere responsen.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; assets får ofte lange TTLs (dage–år) med hashede filnavne.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
Hvert lag bytter friskhed for hastighed: ydre lag er hurtigste men mest tilbøjelige til at være forældet, så sæt lange TTLs + content hashing på virkelig statiske ting og korte TTLs + invalidering på dynamiske.
Det meste latency og load reduction i en web-stack kommer fra caching på det rigtige lag. At vide hvad hvert lag holder og dets typiske TTL lader dig placere en cache hvor det faktisk hjælper, undgå serving af forældet data, og argumentere om hvorfor en ændring ikke dukkede op (hvilket lag serverer stadig en gammel kopi).