ஒரு கோரிக்கை பல கேச் அடுக்குகளைக் கடந்து செல்கிறது, ஒவ்வொன்றும் பயனரை நெருங்கி வேகமாக செயல்படுகிறது ஆனால் குறைவாக சேமிக்கிறது. பயனரிலிருந்து முடிந்தளவு வெளிப்புறமாக (கிளையன்टுக்கு நெருக்கமாக) பதிலளிக்கும் கருத்து, மேலும் மேல்புறத்தில் எதுவும் பதிலை வழங்க முடியாதபோது மட்டுமே origin க்கு வீழ்ச்சி அடைந়தாக மாறும்.
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
ஒவ்வொரு அடுக்கும் freshness க்கு வேகத்தை பரிமாற்றம் செய்கிறது: வெளிப்புற அடுக்குகள் வேகமாக ஆனால் அதிகம் stale ஆனவை, எனவே நீண்ட TTL + content hashing ஐ உண்மையான static விஷயங்களில் வைக்கவும் மற்றும் short TTL + invalidation ஐ dynamic விஷயங்களில் வைக்கவும்.
வெப் ஸ்டாக்கில் பெரும்பாலான latency மற்றும் load குறைப்பு சரியான அடுக்கில் caching இலிருந்து வருகிறது. ஒவ்வொரு அடுக்கும் என்ன வைத்திருக்கிறது மற்றும் அதன் வழக்கமான TTL ஐ அறிந்துகொள்வது ஒரு கேச்சை அது உண்மையில் உதவும் இடத்தில் வைக்க, stale தரவை வழங்குவதை தவிர்க்க, மற்றும் ஏன் ஒரு மாற்றம் தோன்றவில்லை என்பதை காரணம் கூறுவதை அனுமதிக்கிறது (எந்த அடுக்கு இன்னும் ஒரு பழைய நকல் வழங்கிக் கொண்டிருக்கிறது).