Herkes hızlı yanıt sürelerine bayılır. Yeni dashboard'un yüklenmesi 4 saniye sürdüğünde, anında bulunan çözüm önüne Redis koymak oldu. Cache Guy o sprint'in kahramanıydı.
Ancak Tiny CTO'nun bildiği gibi, doğruluk olmadan hız, sadece yanlış cevabı daha hızlı teslim etmektir.
Bu bölüm aslında ne hakkında
Bu bölüm agresif caching'in baştan çıkarıcı tuzağını inceliyor. Caching genellikle yavaş sorgular, indekslenmemiş veritabanı tabloları veya verimsiz API'ler için bir yara bandı olarak kullanılır. İşler yolunda giderken mükemmel çalışır, ancak durum (state) değiştiğinde, invalidation (geçersiz kılma) karmaşıklığı çirkin yüzünü gösterir.
Teknik Çıkarım
Bilgisayar Bilimlerinde sadece iki zor şey vardır: cache invalidation ve isimlendirme. Tek geçersiz kılma stratejisi olarak Time-To-Live (TTL) süresine güveniyorsanız, kullanıcılarınızın tam olarak o TTL penceresi boyunca bayat verileri göreceğini matematiksel olarak garanti ediyorsunuz demektir.
Gerçek Takımlarda Nasıl Görünür?
Bunu, envanterde 'Stokta Var' yazan ama ödeme sayfasında (checkout) hata veren e-ticaret sitelerinde veya kullanıcıların profillerini güncellediği ancak eski avatarlarının 24 saat boyunca görünmeye devam ettiği SaaS dashboard'larında görürsünüz. Ekip, P99 latency (gecikme) düşüşünü kutlarken, müşteri destek biletlerindeki 'garip glitch' artışını görmezden gelir.
Takımların dikkat etmesi gerekenler
Cache Guy'ın aslında veritabanını hiç kontrol etmediğine dikkat edin; sadece beş dakika önce elinde ne varsa kendinden emin bir şekilde onu uzatıyor. Caching katmanınızın sadece kör bir expiration (sona erme) zamanlayıcısına değil, deterministik ve event-driven (olay güdümlü) bir geçersiz kılma stratejisine sahip olması gerekir.
Teknik Çıkarım
Caching, optimize edilmiş bir veritabanı sorgusunun yerini tutamaz; o, karmaşık bir dağıtık state problemidir.
Gerçek Takımlarda Nasıl Görünür?
Bu durum, ekiplerin kötü mimari için bir koltuk değneği olarak Redis veya Memcached kullandıklarında ortaya çıkar ve UI ile veritabanının gerçek konusunda anlaşamadığı split-brain senaryolarına yol açar.
Sıkça Sorulan Sorular
Bu bölümdeki teknik ders nedir?
Ders, caching'in tasarımsal olarak state tutarsızlığı getirdiğidir ve cache'i uygulamadan önce geçersiz kılmayı (invalidation) nasıl yöneteceğinizi planlamanız gerekir.
Bu problem neden production'da ortaya çıkar?
Çünkü TTL tabanlı caching, test sırasında tek kullanıcıyla gayet iyi çalışır, ancak production'da eşzamanlı (concurrent) güncellemeler ve okumalar altında başarısız olur.
Mühendislik ekipleri bu pattern'dan nasıl kaçınabilir?
Önce altta yatan sorguyu optimize edin. Caching gerekliyse, sadece TTL'e güvenmek yerine event-driven bir geçersiz kılma stratejisi (yazma işleminde açık silme ile cache-aside gibi) uygulayın.