En förfrågan passerar genom flera cachningslager, där varje lager är närmare användaren och serverar snabbare men håller mindre data. Idén är att svara så långt ut (nära klienten) som möjligt och endast falla igenom till ursprunget när inget uppströms kan servera svaret.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; tillgångar får ofta långa TTL:er (dagar–år) med hashade filnamn.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
Varje lager gör avvägningar mellan färskhet och hastighet: yttre lager är snabbast men mest troligt inaktuella, så använd långa TTL:er + innehållshashing på verkligt statiska saker och korta TTL:er + invalidering på dynamiska.
Det mesta av latens och belastningsminskning i en webstack kommer från cachning på rätt lager. Att veta vad varje lager innehåller och dess typiska TTL låter dig placera en cache där den faktiskt hjälper, undvika att servera inaktuell data och resonera om varför en ändring inte visades (vilket lager serverar fortfarande en gammal kopia).