Permintaan melalui lapisan cache berkali-kali, masing-masing lebih dekat ke pengguna yang melayani lebih cepat tetapi memegang lebih sedikit. Ideanya adalah untuk menjawab sejauh mungkin (dekat dengan klien) dan hanya jatuh ke asal ketika tidak ada yang hilir dapat melayani respons.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; aset sering mendapat TTL panjang (hari–tahun) dengan nama file yang di-hash.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
Setiap lapisan menukar kesegaran untuk kecepatan: lapisan luar paling cepat tetapi kemungkinan paling basi, jadi letakkan TTL panjang + hash konten pada hal-hal yang benar-benar statis dan TTL pendek + invalidasi pada hal-hal dinamis.
Sebagian besar pengurangan latensi dan beban dalam stack web berasal dari caching di lapisan yang tepat. Mengetahui apa yang disimpan setiap lapisan dan TTL tipikal memungkinkan Anda menempatkan cache di mana benar-benar membantu, menghindari penyajian data basi, dan bernalar tentang mengapa perubahan tidak muncul (lapisan mana yang masih melayani salinan lama).