Pyyntö kulkee useiden cache-tasojen läpi, joista jokainen on lähempänä käyttäjää ja palvelee nopeammin, mutta sisältää vähemmän dataa. Ideana on vastata mahdollisimman lähellä asiakasta ja vain siirtyä alkuperään, kun mikään upstream-taso ei pysty palvelemaan vastausta.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; resursseille asetetaan usein pitkät TTL:t (päivät–vuosi) hash-muodostetuilla tiedostonimillä.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
Jokainen taso tekee kompromissin tuoreuuden ja nopeuden välillä: ulommat tasot ovat nopeampia mutta todennäköisemmin vanhentuneita, joten aseta pitkät TTL:t + sisällön hashing todella staattisille asioille ja lyhyet TTL:t + invalidointi dynaamisille.
Suurin osa web-stackin latenssin ja kuorman vähenemisestä tulee cachettamisesta oikealla tasolla. Tieto siitä, mitä kukin taso sisältää ja sen tyypillinen TTL, antaa sinulle mahdollisuuden sijoittaa cache sinne, missä se todella auttaa, välttää vanhentuneita dataa, ja perustella, miksi muutos ei näkynyt (mikä taso palvelee yhä vanhaa kopiota).