একটি অনুরোধ একাধিক ক্যাশ স্তরের মধ্য দিয়ে যায়, প্রতিটি ব্যবহারকারীর কাছাকাছি থাকা দ্রুত পরিবেশন করে কিন্তু কম ডেটা ধারণ করে। ধারণা হল যতটা সম্ভব বাইরের দিকে (ক্লায়েন্টের কাছাকাছি) উত্তর দেওয়া এবং শুধুমাত্র তখনই মূল উৎসে পৌঁছানো যখন উপরিস্থ কিছুই প্রতিক্রিয়া পরিবেশন করতে পারে না।
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag দ্বারা নিয়ন্ত্রিত; সম্পদগুলি প্রায়ই হ্যাশড ফাইলনামের সাথে দীর্ঘ TTL (দিন–বছর) পায়।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
প্রতিটি স্তর তাজাপনের জন্য গতি বাণিজ্য করে: বাহ্যিক স্তরগুলি দ্রুততম কিন্তু সবচেয়ে সম্ভবত বাসি, তাই সত্যিকারের স্ট্যাটিক জিনিসে দীর্ঘ TTL + কন্টেন্ট হ্যাশিং রাখুন এবং ডায়নামিক জিনিসে ছোট TTL + অবৈধতা রাখুন।
ওয়েব স্ট্যাকে বেশিরভাগ লেটেন্সি এবং লোড হ্রাস সঠিক স্তরে ক্যাশিং থেকে আসে। প্রতিটি স্তর কী ধারণ করে এবং এর সাধারণ TTL জানা আপনাকে ক্যাশ এমন জায়গায় রাখতে দেয় যেখানে এটি সত্যিই সাহায্য করে, বাসি ডেটা পরিবেশন এড়ায়, এবং কেন একটি পরিবর্তন প্রদর্শিত হয়নি তা সম্পর্কে যুক্তি করতে দেয় (কোন স্তর এখনও একটি পুরাতন কপি পরিবেশন করছে)।