Yazılar · 02.05.26 · 1 dk

Cache invalidation: pub/sub her zaman cevap değil

Key tasarımı, TTL ve invalidation stratejisi — production'da sessizce patlayan üç nokta.

Cache invalidation: pub/sub her zaman cevap değil

"Önbellek geçersiz kılma zor bir problemdir" cümlesi doğru. Asıl hata, strateji seçmeden önce okuma/yazma oranını ve "ne kadar eski veri kabul edilir?" sorusunu yazmamak. E-ticarette ürün kartı sayfası günde binlerce okunur, günde birkaç kez güncellenir; burada agresif önbellek ve kısa yaşam süresi (TTL) mantıklı. Sepet ve stok rezervasyonunda tolerans sıfıra yakın — tamamen farklı bir strateji gerekir.

Yayınla-abone ol (pub/sub) ile tüm sunuculara "bu önbelleği sil" mesajı göndermek hızlı görünür ama bir mesaj kaçırılırsa veri sonsuza kadar eski kalır. Yeniden deneme ve ölü mektup kuyruğu (DLQ) yoksa gece yayınında sessiz bozulma yaşanabilir. Alternatif olarak sürümlü anahtar kullanmayı seviyorum: fiyat güncellenince urun:123:v42 yerine v43 yazılır, eski anahtar TTL ile kendiliğinden silinir. Pub/sub karmaşıklığı olmadan aynı hedefe varırsın.

Cache invalidation stratejileri Stratejiyi sunumdan değil ölçümden seçmek lazım: önbellek isabet oranı, eski veri kaynaklı olay sayısı, önbellek kaçırıldığında veritabanı yükü. Ölçmeden "Redis'e geçtik, bitti" demek yetmez.

Özet: Her veri aynı önbellek stratejisini hak etmez. Okuma/yazma oranı ve tutarlılık ihtiyacı önce yazılmalı.

Cache invalidation: pub/sub her zaman cevap değil — Aziz Osmanoğlu