A kérés több cache rétegtől halad át, mindegyik közelebb van a felhasználóhoz, gyorsabban szolgál, de kevesebbet tárol. Az ötlet az, hogy a lehető legtávolabb (közel a klienshez) válaszolj, és csak akkor menj az eredethez, ha a felsőbb rétegek közül egyik sem képes az választ.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag vezérli; az eszközök gyakran hosszú TTL-t (nap-év) kapnak kivonatolt fájlnevekkel.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
Minden réteg frissességet cserél sebességre: a külső rétegek a leggyorsabbak, de leginkább elavultak, ezért helyezz hosszú TTL-t + tartalomhasználatot a valóban statikus dolgokra, és rövid TTL-t + érvénytelenítést a dinamikus dolgokra.
A web stackban a legtöbb késleltetés és terheléscsökkentés a helyes réteген történő gyorsítótárazásból származik. Az a tudás, hogy minden réteg mit tárol, és a jellemző TTL-je lehetővé teszi, hogy a cache-t oda helyezd, ahol ténylegesen segít, kerüld a régi adatok kiszolgálását, és gondolkodj azon, miért nem jelent meg egy változás (melyik réteg még mindig régi másolatot szolgál).