Redis Önbellekleme Stratejileri: Cache-Aside, Write-Through ve Ötesi

Önbellekleme (Caching), modern web uygulamalarında performansı artırmanın en etkili yollarından biridir. Ancak "veriyi Redis'e koyalım, hızlı çalışsın" demek, genellikle felaketin başlangıcıdır. Cache, doğru kullanılmadığında veritabanınızdan daha büyük bir baş ağrısına dönüşebilir. Verinin ne zaman güncelleneceği, ne zaman silineceği ve tutarlılığın nasıl sağlanacağı, seçtiğiniz stratejiye bağlıdır.

Bu yazıda, sahada en sık kullandığımız desenleri, avantajlarını ve en önemlisi tuzaklarını inceleyeceğiz.

1. Cache-Aside (Lazy Loading): Standart Seçim

En yaygın ve genellikle varsayılan olarak kullanılan desendir. Mantığı basittir: Uygulama tembeldir, veriyi önce cache'te arar.

1. Cache'e bak: Veri var mı? Varsa (Cache Hit), harika, hemen dön.
2. Yoksa (Cache Miss): Veritabanına git, veriyi oku.
3. Cache'e yaz: Veritabanından aldığın veriyi cache'e yaz ki bir dahaki sefere bulabilesin.
4. Dön: Veriyi kullanıcıya ver.

async function getUser(userId) {
    // 1. Cache'e bak
    const cachedUser = await redis.get(`user:${userId}`);
    if (cachedUser) return JSON.parse(cachedUser);

    // 2. DB'den oku
    const user = await db.findUser(userId);

    // 3. Cache'e yaz (TTL ile - Burası kritik!)
    if (user) {
        await redis.set(`user:${userId}`, JSON.stringify(user), 'EX', 3600);
    }

    return user;
}

Neden Severiz?

• Sadece gerçekten istenen veri cachelenir. Cache belleğini çöplüğe çevirmezsiniz.
• Cache çökerse sistem çalışmaya devam eder (biraz yavaşlar ama durmaz).

Tuzakları Neler?

• Cold Start: İlk istek her zaman yavaştır çünkü cache boştur.
• Stale Data (Bayat Veri): Veritabanında veri güncellendiğinde, cache'teki veri eski kalır. TTL (Time To Live) süresi dolana kadar kullanıcı eski veriyi görür. Bu yüzden güncelleme anında cache'i silmek (invalidation) şarttır.

2. Write-Through: Tutarlılık Takıntısı

Bu desende uygulama, veriyi hem cache'e hem de veritabanına aynı anda yazar. Okuma işlemleri ise her zaman cache'ten yapılır.

Avantajı: Cache her zaman günceldir. Veri tutarlılığı (consistency) çok yüksektir. Veritabanında ne varsa, cache'te de o vardır. Dezavantajı: Yazma işlemi yavaştır çünkü iki yere birden yazarsınız (Double Write). Ayrıca, hiç okunmayacak veriler bile cache'e yazılır ve belleği işgal eder.

Genellikle finansal veriler gibi tutarlılığın hızdan daha önemli olduğu durumlarda tercih edilir.

3. Write-Behind (Write-Back): Hız Canavarı

Bu, en riskli ama en hızlı yöntemdir. Uygulama sadece cache'e yazar ve kullanıcıya "Tamam, hallettim" der. Arka planda çalışan bir asenkron işlem (worker), veriyi cache'ten alıp veritabanına yazar.

Avantajı: Yazma performansı muazzamdır. Veritabanı darboğaz olmaz. Dezavantajı: Eğer veritabanına yazılmadan önce cache sunucusu çökerse, veri kaybolur. Geçmiş olsun.

Bu yöntemi genellikle "beğeni sayıları", "görüntülenme sayıları" gibi kaybolması dünyanın sonu olmayan ama çok sık güncellenen verilerde kullanırız.

Cache Stampede (Thundering Herd) Problemi

Yüksek trafikli bir sisteminiz var. Popüler bir ürünün (örneğin yeni çıkan iPhone) cache süresi (TTL) doldu. O an, saniyede 10.000 kişi o ürüne bakıyor.

TTL dolduğu anda, 10.000 istek aynı anda "Cache Miss" yaşar. Hepsi birden "Veriyi ben getireceğim!" diyerek veritabanına saldırır. Veritabanı bu yükü kaldıramaz ve çöker. Veritabanı çökünce uygulama da çöker.

Çözüm:

1. Probabilistic Early Expiration: TTL dolmadan rastgele bir zamanda yenileme yapmak. Yani süre dolmak üzereyken bir şanslı istek veriyi yeniler.
2. Locking: Sadece bir isteğin DB'ye gitmesine izin vermek, diğerlerini bekletmek. "Durun, Ahmet veriyi almaya gitti, o gelince hepimiz kullanacağız" demek.

Sonuç

Hangi stratejiyi seçerseniz seçin, "Cache Invalidation" (Cache Temizleme) bilgisayar bilimlerinin en zor iki probleminden biridir (diğeri isimlendirme). Verinizin ne kadar bayat kalabileceğine (staleness tolerance) karar verin ve stratejinizi ona göre belirleyin.

Unutmayın: Cache, veritabanını korumak için vardır, onun yerini almak için değil.