მოთხოვნა გადის მრავალი cache-ის ფენის მეშვეობით, თითოეული უფრო ახლოსაა მომხმარებელთან და უფრო სწრაფი, მაგრამ ნაკლებ სიმძლავრის. იდეა არის, რომ პასუხი მიეცეს რაც შეიძლება შორიდან (კლიენტთან ახლოს) და მხოლოდ მაშინ მივიდეთ სფეროში, როდესაც არცერთი ზემოთ მოცემული ფენა არ შეუძლია სერვის მიცემა.
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 + შინაარსის hashing-ი ნამდვილად სტატიკური რამეზე და მოკლე TTL + ბათილობა დინამიკურ რამეზე.
ვებ-სტეკის უმეტესი latency და load შემცირება მოდის cache-ირება სწორ ფენაზე. იმის ცოდნა, თუ რა ინახავს თითოეული ფენა და მისი ტიპიური TTL საშუალებას აძლევს cache-ი განათავსოთ იქ, სადაც ის რეალურად ეხმარება, თავი შეიკავოთ მოძველებული მონაცემების მიღებისგან და დაფიქრდეთ, თუ რატომ არ გამოჩნდა ცვლილება (რომელი ფენა აგრძელებს ძველი ასლის მიღებას).