Bir sistemin hızını çoğu zaman yazdığın kod değil, veriye erişim şeklin belirler. Her istekte veritabanına gitmek hem yavaş hem de maliyetlidir. Trafik arttıkça bu sorgular birikir, sistem yavaşlar ve kullanıcı deneyimi bozulur.

Caching, bu sorunun en etkili çözümüdür. Sık kullanılan verileri yakında tutarak yanıt sürelerini düşürür, sistemi rahatlatır ve ölçeklenebilirliği artırır. Doğru kullanıldığında, küçük bir cache katmanı bile performansı katlayabilir.

Bu yazıda, farklı önbellekleme stratejilerinin nasıl çalıştığını ve hangi senaryolarda doğru seçim olabileceğini birlikte keşfedeceğiz. Çünkü iyi bir cache stratejisi, sadece sistemi değil, kullanıcı deneyimini de tasarlar.

Uygulama, Önbellek ve Veritabanı Arasındaki Veri Akışı

Neden Caching’e İhtiyacımız Var?

Bir API düşünelim. Kullanıcı her giriş yaptığında profil bilgilerini, ayarlarını, geçmişini sorguluyor. Her istek doğrudan veritabanına gittiğinde şu üç sorun kaçınılmaz hale gelir:

Gecikme (latency) artar.
Veritabanı yükü yükselir.
Servisler arası bağımlılıklar çoğalır.

Örneğin, mikroservis mimarisi kullanan bir sistemde “User Service” profil verisini “Account Service” üzerinden alıyorsa, her sorgu zincirleme gecikme yaratır.

Caching, bu zinciri kırmanın en etkili yoludur. Sık erişilen verileri yakın bir katmanda — RAM’de, bir Redis node’unda veya uygulama belleğinde — tutarak hem performansı, hem de ölçeklenebilirliği dramatik biçimde artırır.

Amazon'un kendi iç raporlarında belirttiği üzere:

"Her 100ms gecikme, satışları %1 azaltabilir." Bu kadar küçük bir fark bile, cache katmanının neden bu kadar kritik olduğunu açıklamaya yetiyor.

Peki Ne Tür Problemleri Çözüyoruz?

Caching stratejileri yalnızca hız kazandırmaz; aynı zamanda sistemi daha dayanıklı ve daha ekonomik hale getirir:

Uygulamalarda sık karşılaşılan performans darboğazları ve uygun cache stratejileri.

Ancak burada asıl mesele şu: Her şey cache’e alınmaz. Cache’i nerede, nasıl ve ne kadar süreyle tutacağımız; işte burada “Caching Strategies” devreye giriyor.

En yaygın önbellekleme stratejileri

Caching Stratejileri

Aşağıdaki stratejiler, AWS ve büyük ölçekli sistemlerde (Netflix, DoorDash, Uber gibi) en yaygın kullanılan yaklaşımlar. Her biri farklı bir sorunu çözüyor, farklı bir risk taşıyor.

1. Cache-Aside (Lazy Loading)

"İstendiğinde yükle, gerekmedikçe uğraşma."

Bu stratejide uygulama önce cache’e bakar:

Eğer veri varsa (cache hit) → doğrudan döner.
Yoksa (cache miss) → veritabanından çeker, cache’e yazar ve yanıt döner.

Avantajlar ✅ Basit, çoğu senaryoya uygun. ✅ Önbellek sadece gerçekten kullanılan veriyi tutar. ✅ Uygulama mantığı üzerinde tam kontrol sağlar.

Dezavantajlar ⚠️ İlk erişimde “miss” nedeniyle geçici yavaşlama olur. ⚠️ Cache invalidation (geçersizleştirme) manuel yönetilmelidir. ⚠️ Veritabanında yapılan güncellemeler cache’e yansıtılmazsa “stale data” riski oluşur.

Gerçek hayattan örnek: Bir e-ticaret sitesinde kullanıcılar ürün detayını inceliyor. İlk kullanıcı ürün sayfasına girince sistem veritabanından çeker → cache’e yazar. Sonraki binlerce kullanıcı o ürün sayfasına girdiğinde, tüm sorgular doğrudan cache’ten döner. Basit ama etkili.

2. Read-Through & Write-Through

"Uygulama cache'i doğrudan kullanır, sistem otomatik günceller."

Bu yaklaşımda uygulama cache’in arkasında duran veritabanını doğrudan bilmez bile. Cache katmanı, gerektiğinde veritabanına gider ve veri yoksa yükler (Read-Through). Veri yazılırken hem veritabanına hem cache’e aynı anda yazar (Write-Through).

Avantajlar ✅ Tutarlılık yükünü uygulamadan alır. ✅ Cache her zaman günceldir. ✅ Uygulama tarafında ekstra mantık gerekmez.

Dezavantajlar ⚠️ Yazma işlemleri yavaşlar (çünkü iki yere birden yazılır). ⚠️ Büyük hacimli yazmalarda yük artar. ⚠️ Cache katmanı bozulursa sistem tüm yükü DB’ye taşır.

Örnek: Bir kullanıcı profilini güncellediğinde sistem aynı anda hem DB’ye hem cache’e yazar. Okuma işlemleri artık doğrudan cache’ten döner, “cache miss” neredeyse hiç yaşanmaz. Bu strateji özellikle okuma ağırlıklı ve az değişen veriler için idealdir (örneğin ürün katalogu).

3. Write-Behind (Lazy Write)

"Önce cache'e yaz, veritabanına sonra uğrarız."

Burada sistem önce cache’e yazar, ardından asenkron bir işlemle (örneğin background worker veya queue üzerinden) veritabanına yazar. Böylece kullanıcı açısından yazma işlemi anında tamamlanmış olur.

Avantajlar ✅ Performans müthiştir — kullanıcı hemen yanıt alır. ✅ Veritabanı üzerindeki yazma yükü dağılır. ✅ Yüksek hacimli “eventual consistency” sistemleri için uygundur.

Dezavantajlar ⚠️ Sistem çökmeden önce veritabanına yazılmamış veriler kaybolabilir. ⚠️ “Sonradan tutarlılık” (eventual consistency) gerektirir. ⚠️ Hatalı retry mekanizmaları duplicate veri oluşturabilir.

Örnek: Bir sosyal medya platformunda beğeni sayıları sürekli değişir. Her “like” işlemini anında veritabanına yazmak büyük yük yaratır. Bunun yerine sistem önce cache’e yazar, arka planda periyodik olarak DB’ye senkronize eder. Kullanıcı sayacı hemen artar, ancak kesin sayı birkaç saniye sonra DB’de güncellenir.

4. Write-Around

"Veri yazıldığında cache'i atla; sadece okuma sırasında doldur."

Bu stratejide yeni yazılan veriler direkt veritabanına gider; cache sadece okuma işlemlerinde kullanılır.

Avantajlar ✅ Cache, gerçekten ihtiyaç duyulan verilerle dolar. ✅ Gereksiz cache kirlenmesi (pollution) önlenir.

Dezavantajlar ⚠️ Yeni yazılmış veriler ilk okuma sırasında cache’te bulunmaz (miss). ⚠️ Yüksek okuma trafiğinde sık miss yaşanabilir.

Örnek: Bir blog sisteminde yeni gönderiler sürekli ekleniyor. Ancak okuyucular genellikle “popüler” yazılara gidiyor. Bu durumda yeni yazıları cache’e koymak gereksiz; sadece okunanları cache’e almak daha mantıklı.

Gerçek Hayat Hikayesi: DoorDash Nasıl Yaptı?

DoorDash, yüzlerce mikroservisten oluşan devasa bir sistem. Zamanla her ekip kendi cache mekanizmasını kurmuş: Redis kullananlar, Caffeine kullananlar, hatta kendi “mini cache” sınıfını yazanlar bile olmuş. Sonuç:

Tutarsız cache key yapıları
Zayıf gözlemlenebilirlik
Invalidasyon karmaşası

Bunun üzerine DoorDash, çok katmanlı merkezi bir caching altyapısı tasarladı:

Request-Local Cache → Her HTTP isteği boyunca yaşayan kısa ömürlü cache
In-Memory (JVM) Cache → Örneğin Caffeine ile mikroservis içinde
Distributed Cache (Redis) → Tüm instancelar arası paylaşılan cache

İstek geldiğinde sistem bu katmanları sırasıyla kontrol ediyor. Böylece en hızlı yanıt her zaman en yakın katmandan sağlanıyor.

Ayrıca “shadow mode” denilen bir teknikle cache performansını gözlemliyorlar: Yeni cache politikası önce sadece loglanıyor, kullanıcıya etkisi olmadan test ediliyor. Hit oranı yeterli seviyeye çıkınca devreye alınıyor.

Bu yapı sayesinde DoorDash:

DB trafiğini %50 azalttı
Ortalama yanıt süresini %30 düşürdü
Cache tutarlılığı problemlerini merkezileştirerek yönetti

Kaynak: https://blog.quastor.org/p/architecture-doordashs-caching-system

Hangi Strateji Ne Zaman Kullanılmalı?

Mimari Düzeyde Dikkat Edilmesi Gerekenler

Cache hiçbir zaman gerçek kaynağın (DB) yerini almaz.
TTL (time-to-live) ayarlarını dikkatle seç: çok kısa olursa miss artar, çok uzun olursa veri bayatlar.
Eviction policy olarak LRU veya LFU tercih et (özellikle Redis’te).
Monitoring şart: hit/miss oranlarını ölç, zamanla ayarlamaları optimize et.
Invalidate erken, doldur geç: Eski veriyi göstermek yeni veriyi göstermemekten daha az risklidir.
Katmanlı cache düşün: local + distributed kombinasyonu her zaman daha dengelidir.

Sonuç

Cache, performans için kullanılan bir “yama” değil, mimari bir stratejidir. Doğru uygulandığında hem veritabanı maliyetini azaltır, hem sistemin dayanıklılığını artırır, hem de kullanıcı deneyimini uçurur.

Ancak yanlış uygulandığında… Sistemlerin “gizli hata kaynağına” dönüşür.

Bu yüzden hatırlanması gereken son kural:

Cache her şeyi hızlandırabilir - yanlış yapılandırılmışsa hataları da.

Umarım bu yazı, kafandaki soru işaretlerini biraz olsun gidermiştir. 😊 Eğer hâlâ karar veremediysen, yorumlara yazabilirsin. 🚀