Żądanie przechodzi przez wiele warstw cache'u, każda bliżej użytkownika, serwująca szybciej, ale przechowująca mniej danych. Idea polega na odpowiadaniu jak najbliżej klienta i tylko przechodzeniu do źródła, gdy żadna upstream warstwa nie może serwować odpowiedzi.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; zasoby często otrzymują długie TTL (dni–rok) z haszowanymi nazwami plików.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
Każda warstwa wymienia świeżość za szybkość: warstwy zewnętrzne są najszybsze, ale najprawdopodobniej przestarzałe, więc umieszczaj długie TTL + haszowanie zawartości na rzeczywiście statycznych rzeczach i krótkie TTL + inwalidację na dynamicznych.
Większ redukcji opóźnień i obciążenia w stosie webowym pochodzi z cache'owania na właściwej warstwie. Wiedza o tym, co przechowuje każda warstwa i jej typowy TTL, pozwala umieścić cache gdzie faktycznie pomaga, uniknąć serwowania przestarzałych danych i zrozumieć, dlaczego zmiana się nie pojawiła (która warstwa wciąż serwuje starą kopię).