Sebuah permintaan melewati beberapa lapisan cache, masing-masing lebih dekat ke pengguna melayani lebih cepat tetapi menahan lebih sedikit. Idenya adalah menjawab sejauh mungkin (dekat dengan klien) dan hanya jatuh ke asal ketika tidak ada upstream yang dapat melayani respons.
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag; aset sering mendapatkan 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 paling mungkin usang, jadi masukkan TTL panjang + hashing konten pada hal-hal yang benar-benar statis dan TTL pendek + invalidasi pada hal-hal dinamis.
Sebagian besar latensi dan pengurangan beban dalam stack web berasal dari cache di lapisan yang tepat. Mengetahui apa yang disimpan setiap lapisan dan TTL tipikal-nya memungkinkan Anda menempatkan cache di mana benar-benar membantu, hindari melayani data usang, dan alasan tentang mengapa perubahan tidak muncul (lapisan mana yang masih melayani salinan lama).