En forespørsel går gjennom flere cachelager, hvor hvert lag er nærmere brukeren og serverer raskere, men holder mindre data. Idéen er å svare så langt ut (nær klienten) som mulig, og bare falle gjennom til opprinnelsen når ingenting oppstrøms kan servere responsen.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; ressurser får ofte lange TTL-er (dager–år) med hashede filnavn.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 aktualitet for hastighet: ytre lag er raskest men mest sannsynlig foreldet, så sett lange TTL-er + innholdshasning på virkelig statiske ting og korte TTL-er + ugyldiggjøring på dynamiske.
Det meste av latens og lastreduksjon i en webstack kommer fra caching på rett lag. Å vite hva hvert lag holder og dets typiske TTL lar deg plassere en cache der den faktisk hjelper, unngå å servere foreldet data, og resonnere om hvorfor en endring ikke dukket opp (hvilket lag serverer fortsatt en gammel kopi).
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner