Önbellekler (caches)

Kısaca: Daha önce alınmış verileri daha hızlı, tekrarlı erişim için tutan ara depolama.

Biraz daha ayrıntılı: Önbellekler birçok düzeyde bulunur — tarayıcıda (HTML/CSS/JS/görüntüler), DNS çözümleyicilerinde (TTL dolana kadar yanıtlar), CDN’lerde veya bir uygulamanın veritabanı bağlantısında. Hedef her zaman daha yavaş özgün kaynakları (ağ, veritabanı) daha seyrek sorgulamak zorunda kalmaktır.

Ayrıntılı

Hayal etmek için yararlı bir yol: her önbellek katmanı hız ile tazelik arasında bir uzlaşmadır. Bir önbellek kullanıcıya ne kadar yakınsa o kadar hızlıdır, ancak eskimiş veri sunma riski de o kadar büyüktür.

• Tarayıcı önbelleği: statik varlıkları (görüntüler, CSS, JS) kullanıcının cihazında yerel olarak saklar — en hızlı katman, ancak cihaz başına ayrı.
• CDN önbelleği: içeriği kullanıcıya coğrafi olarak yakın tutan, küresel dağıtılmış bir sunucu ağı — örn. Vercel’in edge ağı statik Emzett sayfalarını otomatik önbelleğe alır.
• DNS önbelleği: çözümleyiciler TTL dolana kadar yanıtları hatırlar; böylece her istekte tüm DNS zincirini yeniden yürümek zorunda kalmazlar.
• Uygulama/veritabanı önbelleği: örn. pahalı veritabanı sorguları için Redis önbellekleri.

Bu önbelleklerin her biri, özgün veri önbellek güncellenmeden değişirse eskimiş (“stale”) veri sunabilir — önbelleklemenin temel sorunu bu yüzden önbellekleme kendisinden çok zamanında ve doğru geçersiz kılmadır. Bunun için iki temel strateji vardır: zamana dayalı sona erme (önbellek, özgün verinin gerçekten değişip değişmediğine bakmadan sabit bir TTL’den sonra bir girdiyi otomatik atar) ve açık geçersiz kılma (uygulama önbelleğe etkin olarak “bu girdi artık geçersiz” der, örn. bir veritabanı güncellemesinden hemen sonra).

Gerçek sorun olarak önbellek tutarlılığı

Aynı anda birkaç önbellek katmanıyla (tarayıcı, CDN, uygulama) aynı istek, katmana bağlı olarak farklı güncellikte yanıtlar verebilir — bir kullanıcı örneğin tarayıcı önbelleğinde hâlâ eski ürün fiyatını görürken CDN çoktan yenisini sunuyor olabilir. Cache-Control ve ETag gibi HTTP başlıkları tam olarak bunu denetler:

Cache-Control: max-age=3600, must-revalidate
ETag: "a1b2c3d4"

max-age, bir istemcinin yanıtı yeni istek yapmadan ne kadar süre kullanabileceğini belirtir; must-revalidate ardından (eskimiş sürümü basitçe kullanmaya devam etmek yerine) sunucuyla yeniden kontrol etmeyi zorunlu kılar; ETag içeriğin bir parmak izidir ve sunucunun bu kontrol sırasında, tüm yanıtı yeniden iletmeden gerçekten bir şeyin değişip değişmediğini verimli denetlemesini sağlar (değişmediyse 304 Not Modified yanıtı).

Emzett’te bilerek önbelleğe ALINMAYAN bir alan örneğin sepet durumudur — burada birkaç saniyelik ömürlü bir önbellek bile yanlış stok düzeylerini gösterme konusunda gerçek bir risk olurdu.

Ayrıca bak: Önbellekleme (caching), TTL