Önbellek Stratejileri: Ne Zaman, Nerede ve Ne Kadar Süre?

Önbellek stratejileri, performans çalışmalarının en hızlı sonuç veren aracıdır — ve aynı zamanda en çok "açıklanamayan" hatanın kaynağıdır. Kullanıcı fiyatı günceller, sayfa eski fiyatı gösterir; bir kullanıcı diğerinin verisini görür; sunucuda düzeltilen hata tarayıcıda devam eder. Bu sorunların hepsi aynı yerden gelir: veriyi saklamak kolaydır, ne zaman atılacağına karar vermek zordur.

Önce ölçün, sonra önbellekleyin

Önbellek, yavaşlığın sebebini çözmez, üstünü örter. Eksik bir indeks yüzünden 900 ms süren sorguyu önbelleğe almak sorunu bugün gizler; önbellek boşaldığında veya trafik arttığında aynı sorun geri döner, bu kez daha büyük ölçekte. Bu yüzden sıra nettir: önce ölçün, kolayca düzeltilebilecek sorunları düzeltin, ardından kalan maliyet için önbellek kullanın. Ölçerek başlama ve N+1 sorgu problemi yazılarımız bu ilk adımı ele alıyor.

Katmanlar: isteği ne kadar dışarıda karşılarsanız o kadar iyi

Bir isteğin maliyeti, sisteme ne kadar derin indiğine bağlıdır. Dolayısıyla önbellek kararı, "nerede saklayayım" sorusundan önce "bu isteği ne kadar dışarıda durdurabilirim" sorusudur.

• Tarayıcı önbelleği: Statik varlıklar (JS, CSS, görsel) için en ucuz katmandır. Dosya adına sürüm damgası eklendiğinde çok uzun süreli önbellekleme güvenle yapılabilir.
• CDN: Herkese aynı görünen sayfa ve varlıklar için. Kişiye özel içerikte dikkatli olunmalıdır — yanlış yapılandırma, bir kullanıcının sayfasının başkasına sunulmasına yol açabilir.
• Uygulama önbelleği: Hesaplanmış sonuçlar, ağır sorgu çıktıları, dış API yanıtları. Esneklik burada en yüksektir.
• Veritabanı: Motorun kendi tampon havuzu zaten çalışır; buradaki iyileştirme genellikle önbellek eklemek değil, bellek ayarını ve indeksleri düzeltmektir.

Süre seçimi: en zor karar

Yaşam süresi (TTL) seçiminde tek doğru yoktur, ancak iyi bir yöntem vardır: verinin ne kadar eski olmasına iş açısından katlanılabileceğini sormak. Bir haber listesinde 60 saniyelik eskilik sorun değildir; stok adedinde 60 saniye, satılmayan ürün veya iki kez satılan son parça demektir.

Pratik bir sınıflandırma şudur: nadiren değişen referans verileri (ülke listesi, kategori ağacı) uzun süre; sık okunan ama gecikmeye toleranslı veriler (popüler yazılar, sayaçlar) kısa süre; kritik tutarlılık gerektiren veriler (bakiye, stok) ise ya hiç önbelleklenmez ya da yazma anında hedefli olarak temizlenir. Bu tür alanlarda eşzamanlılık davranışını izolasyon seviyeleri yazımızda ayrıntılandırıyoruz.

Geçersiz kılma: hedefli temizlik

Süreye güvenmek en basit stratejidir ama her zaman yetmez. İkinci yaklaşım, veri değiştiğinde ilgili anahtarı silmektir. Bu daha doğru sonuç verir, ancak "hangi anahtarlar etkilendi?" sorusunu doğru cevaplamayı gerektirir — bir ürün güncellendiğinde ürün sayfası, kategori listesi, arama sonucu ve ana sayfa bloğu etkilenebilir.

Bu yüzden olgun sistemlerde anahtarlar etiketlenir veya sürümlenir: ürün sürümü artırıldığında, o ürüne bağlı tüm anahtarlar bir anda geçersizleşir. Sürüm tabanlı yaklaşımın avantajı, silinecek anahtarların listesini bilmeye gerek kalmamasıdır.

Cache stampede: hepsi aynı anda boşalırsa

Popüler bir anahtarın süresi dolduğu anda yüzlerce istek aynı anda önbelleği boş bulur ve hepsi aynı pahalı sorguyu çalıştırır. Sonuç, tam da önbelleğin engellemesi gereken şeydir: veritabanının aniden çökmesi.

Üç pratik korunma vardır: sürelere küçük rastgelelik eklemek (hepsi aynı saniyede dolmasın), yalnızca bir isteğin yenileme yapmasına izin veren bir kilit kullanmak ve süre dolmadan biraz önce arka planda yenilemek. Sonuncusu kullanıcı deneyimi açısından en iyisidir: hiçbir istek bekleme yaşamaz.

En sık yapılan hatalar

Kişiye özel veriyi ortak anahtarla saklamak. Anahtarda kullanıcı kimliği yoksa, bir kullanıcının verisi başkasına gösterilir. Bu yalnızca hata değil, güvenlik olayıdır.

Önbelleği kalıcı depo sanmak. Önbellek her an boşalabilir; boşaldığında sistem doğru çalışmaya devam etmelidir. Yalnızca önbellekte duran veri, veri kaybıdır.

Hata yanıtlarını önbelleklemek. Geçici bir hata uzun süreyle saklandığında, sorun çözüldükten sonra bile kullanıcılar hatayı görmeye devam eder.

Ölçmemek. İsabet oranı bilinmeyen bir önbellek, işe yarayıp yaramadığı bilinmeyen bir önbellektir. Düşük isabet oranı genellikle anahtarların gereğinden fazla ayrıştırıldığını gösterir.

Uygulama içi örnek: kilitli yenileme

Kuyruk ve arka plan işleriyle birlikte kullanıldığında önbellek yenileme, istek yolundan tamamen çıkarılabilir. Bu desen özellikle ağır raporlarda değerlidir: kullanıcı her zaman hazır veriyi görür, hesaplama zamanlanmış bir işte yapılır. Yavaş uçları kod değiştirmeden hızlandırmanın diğer yolları için ilgili yazımıza bakabilirsiniz. HTTP düzeyindeki önbellek başlıklarının doğru kullanımı için web.dev performans rehberleri güncel bir kaynaktır.

Sonuç

Önbellek, doğru kullanıldığında en yüksek getirili performans aracıdır; yanlış kullanıldığında ise açıklaması en zor hataları üretir. Doğru sıra şudur: önce ölçün ve kök nedeni düzeltin, isteği mümkün olan en dış katmanda durdurun, süreyi verinin iş toleransına göre seçin, kritik veriyi yazma anında hedefli olarak temizleyin ve isabet oranını izleyin. Bugün yapabileceğiniz en faydalı kontrol şudur: önbelleğinizi tamamen boşaltın ve sistemin ne kadar yavaşladığına bakın. Çıkan sayı, gizlediğiniz gerçek maliyettir.