ਇੱਕ ਰਿਕੁਏਸਟ ਮਲਟੀਪਲ ਕੈਸ਼ ਲੇਅਰਜ਼ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ, ਹਰ ਇੱਕ ਪ੍ਰਯੋਗਕਾਰ ਦੇ ਨਜ਼ਦੀਕ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਘੱਟ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਜੋ ਵੀ ਪ੍ਰਯੋਗਕਾਰ ਦੇ ਕੋਲ ਹੋ ਉੱਥੇ ਨਿਵੇਸ਼ ਕਰਿਆ ਜਾਵੇ (ਕਲਾਇੰਟ ਦੇ ਨਜ਼ਦੀਕ) ਅਤੇ ਸਿਰਫ਼ ਓਰੀਜਿਨ ਤੱਕ ਪਹੁੰਚੋ ਜਦੋਂ ਅੱਪਸਟ੍ਰੀਮ ਵਿੱਚ ਕੋਈ ਵੀ ਜਵਾਬ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦਾ।
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest) (closest to data)
Cache-Control/ETag ਦੁਆਰਾ ਕੰਟ੍ਰੋਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; ਸੰਪੱਤੀਆਂ ਅਕਸਰ ਲੰਬੇ TTLs (ਦਿਨ–ਸਾਲ) ਨਾਲ hashed filenames ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ।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 ਲਈ speed ਦਾ ਟ੍ਰੇਡ-ਆਫ ਕਰਦੀ ਹੈ: ਬਾਹਰੀ ਪਰਤਾਂ ਸਭ ਤੋਂ ਤੇਜ਼ ਹੁੰਦੀਆਂ ਹਨ ਪਰ ਸਭ ਤੋਂ ਵਧੀਕ stale ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਲੰਬੇ TTLs + content hashing ਨੂੰ ਸੱਚਮੁੱਚ ਸਥਿਰ ਸੰਸਾਧਨਾਂ ਤੇ ਰੱਖੋ ਅਤੇ ਛੋਟੇ TTLs + invalidation ਨੂੰ ਗਤੀਸ਼ੀਲ ਸੰਸਾਧਨਾਂ ਤੇ।
ਵੈੱਬ ਸਟੈਕ ਵਿੱਚ ਜ਼ਿਆਦਾ latency ਅਤੇ load ਕਮੀ ਸਹੀ ਪਰਤ ਤੇ caching ਤੋਂ ਆਉਂਦੀ ਹੈ। ਜਾਣਨਾ ਕਿ ਹਰੇਕ ਪਰਤ ਕਿਹੜਾ ਡਾਟਾ ਰੱਖਦੀ ਹੈ ਅਤੇ ਇਸਦੀ ਆਮ TTL ਤੁਹਾਨੂੰ cache ਨੂੰ ਓਸ ਥਾਂ ਤੇ ਰੱਖਣ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਸੱਚਮੁੱਚ ਮਦਦ ਕਰੇ, stale data serve ਕਰਨ ਤੋਂ ਬਚੋ, ਅਤੇ ਤਰਕ ਕਰੋ ਕਿ ਕੋਈ ਪਰਿਵਰਤਨ ਕਿਉਂ ਨਹੀਂ ਦਿਸਿਆ (ਕਿਹੜੀ ਪਰਤ ਅਜੇ ਭੀ ਪੁਰਾਣੀ ਕਾਪੀ serve ਕਰ ਰਹੀ ਹੈ)।