Onbellek Desenleri: Cache-Aside, Write-Through ve Write-Behind

Onbellekleme backend dünyasında en yüksek getirili optimizasyon tekniklerinden biridir. Ancak yanlış tasarlandığında en zor teşhis edilen veri tutarlılığı hatalarını da burada görürüz. Birçok ekip Redis ekleyip TTL tanımladıktan sonra problemin çözüldüğünü varsayar. Gerçekte ise yazma sonrası bayat veri, yoğun trafikte cache stampede, eksik invalidation ve veritabanı ile cache arasındaki sessiz ayrışma gibi sorunlar hızla ortaya çıkabilir.

Bu yüzden onbellek kararı bir "performans tweak'i" değil, açık bir mimari tercih olarak ele alınmalıdır. Cache-Aside, Write-Through ve Write-Behind desenleri farklı öncelikleri optimize eder: okuma gecikmesi, yazma maliyeti, dayanıklılık, operasyonel basitlik ve tutarlılık garantileri. Hangi deseni neden seçtiğinizi netleştirmek, ileride oluşacak pahalı yeniden tasarımları önler.

Cache-Aside deseni

Cache-Aside (lazy loading) en yaygın yaklaşımdır. Uygulama önce cache'e bakar; miss olursa veritabanından okur, sonucu cache'e yazar ve kullanıcıya döner. Yazma tarafında genellikle önce veritabanı güncellenir, ardından ilgili anahtar invalidate edilir veya yeniden doldurulur.

Avantajları:

• Kademeli geçiş için pratiktir.
• Sadece gerçekten sık okunan veriler cache'e taşınır.
• Cache ve veritabanı katmanı gevşek bağlı kalır.

Riskleri:

• Invalidation atlanırsa bayat veri.
• Aynı anahtarda eşzamanlı miss durumunda stampede.
• Servisler arasında tutarsız TTL tercihleri.

Bu deseni güçlendirmek için request coalescing, TTL jitter ve domain bazlı invalidation sözleşmeleri eklenmelidir.

Write-Through deseni

Write-Through modelinde yazma anında hem cache hem veritabanı güncellenir. Böylece başarılı write sonrası okuma tarafında taze veri alma olasılığı yükselir.

Avantajlar:

• Read-after-write tutarlılığı daha güçlüdür.
• Sık erişilen varlıklarda yüksek cache hit oranı sağlar.
• Okuma tazeliği davranışı daha öngörülebilir hale gelir.

Trade-off'lar:

• Yazma gecikmesi artar; cache yazımı senkrondur.
• Az okunan verilerde gereksiz write amplification oluşur.
• Hata yönetimi karmaşıklaşır; iki katman birlikte ele alınır.

Kullanıcı ayarları, hesap durumları gibi yazma sonrası hemen doğru okunması gereken alanlarda Write-Through iyi sonuç verir.

Write-Behind deseni

Write-Behind (write-back) modelinde uygulama önce cache'e yazar, kalıcı depoya yazma asenkron şekilde sonra yapılır. Bu yaklaşım algılanan yazma gecikmesini ciddi azaltabilir ve ani trafik artışlarını sönümleyebilir; fakat kaynak doğruluk katmanına yazma geciktiği için risk de artar.

Avantajlar:

• Çok düşük yazma gecikmesi.
• Pik trafik altında daha yumuşak davranış.
• Toplu yazma senaryolarında throughput avantajı.

Riskler:

• Flush öncesi cache arızasında veri kaybı.
• Bağımlı yazmalarda sıralama karmaşıklığı.
• Kısmi hata sonrası toparlanma süreçlerinin zorlaşması.

Write-Behind kullanılacaksa kalıcı kuyruk veya işlem günlüğü ile birlikte düşünülmelidir. Kritik iş verisini yalnızca bellekte tutmak kabul edilebilir bir risk değildir.

Tutarlılık ve invalidation sahipliği

Cache kaynaklı üretim hatalarının çoğu invalidation kaynaklıdır. Anahtar yaşam döngüsünün sahibi net tanımlanmalıdır:

• Commit sonrası mı invalidate edilecek?
• Domain event tüketiminde mi güncellenecek?
• Arka plan uzlaştırma işiyle mi temizlenecek?

Aynı veri için birden fazla invalidation yolu tanımlanacaksa öncelik sırası açık olmalıdır. Event-driven invalidation ölçeklenebilir bir modeldir; ancak teslimat garantileri ve idempotency stratejisi net değilse yeni tutarsızlıklar üretir.

TTL değerleri de rastgele seçilmemelidir. TTL, performans ile doğruluk arasındaki risk bütçesidir. Kısa TTL veritabanı yükünü artırır, uzun TTL bayat veri riskini büyütür. İş etkisine göre alan bazlı belirlenmelidir.

Stampede ve hot-key çöküşünü önlemek

Yüksek trafikte aynı anahtarın peş peşe miss olması veritabanını hızlıca zorlayabilir. Yaygın önlemler:

• Tek anahtar için single-flight deduplikasyon.
• Olasılıksal erken yenileme (probabilistic refresh).
• Soft TTL ve arka plan yenileme.
• Hot-key parçalama ve yerel process cache fallback.

Bu mekanizmalar gerçekçi yük testlerinde doğrulanmalıdır; yalnızca staging gözlemi yeterli değildir.

Üretime alma kontrol listesi

Onbelleklemeyi adım adım genişletmek daha güvenlidir:

1. Başlangıç latency ve DB yük metriklerini ölç.
2. Tek endpoint veya tek varlık tipinde cache'i aç.
3. Hit oranı, bayat veri geri bildirimleri ve hata dağılımını izle.
4. Invalidation ve stampede korumalarını ekle.
5. Domain bazlı runbook ile kapsama alanını büyüt.

Takip edilmesi gereken metrikler: hit/miss oranı, miss cezası, stale read sıklığı, write propagation gecikmesi, eviction churn. Bunlar olmadan cache başarısı ölçülmez, varsayılır.

Onbellek yalnızca performans değil, aynı zamanda tutarlılık mühendisliğidir. Deseni bilinçli seçen, riskleri ölçen ve operasyonel görünürlük kuran ekipler; hem hız kazanır hem de doğruluktan ödün vermez.