Redis'i kurunca her şey hızlanır gibi görünür; ilk hafta herkes "onu da Redis'e koyalım" der. Sonra bir sabit stoklar veri kaybolur, bir sabit de bellek dolar. Fark, zekâ değil ayrım sanatıdır: Redis'e giren her şeyin kaybolabilir olması, girmeyen her şeyin ise tek doğruluk kaynağında kalması gerekir. Bu ayrımı yapan üç soru ve birkaç pratik kural var.

Ayrımı iyi yapan ekip ile yapmayan arasında altı ay sonra görünür bir fark oluşur: biri Redis'i bir araç gibi kullanır, öteki onu ikinci bir veritabanı hâline getirip bakımını da üstlenmek zorunda kalır. Aşağıdaki iki liste, bu farkı doğuran kararların yaprak hâlidir.

Redis'e ne konur

Ortak payda üç koşul: kaybı tolere edilebilir, yeniden üretilebilir ve hız kritik. Bu üçlüye uyanlar saymakla bitmez ama başlıcaları bellidir. Oturum verileri, kullanıcı isteklerini sınırlayan sayaçlar, kısa ömürlü tek kullanımlık token'lar, dağıtık kilitler, sıralama tabloları, işlem günlüğü tabanlı basit kuyruklar ve tabii ki veritabanından önce bakılan önbellek sayfaları.

-- Önbellek sayfası: değer + yaşam süresi birlikte
SETEX urun:42:detay 300 "json;urun-detayi"
INCR istek:8452:2026-07-06
EXPIRE istek:8452:2026-07-06 86400
SETEX kilot:rapor 10 sahibi=8452

Sayaç ve kilit örnekleri tesadüf değil: Redis'in atomik komutları bu işleri tek komutla yapar, veritabanı ise bunu ancak satır kilitleme masrafıyla simüle eder.

Redis'e ne konmaz

Birinci grup, tek doğruluk kaynağı olan verilerdir: kullanıcı profili, şifre özeti, fatura satırı, stok hareketi. Redis bellek tabanlıdır ve kalıcılık ikinci sınıf vatandaşlıktır; yeniden başlarken anlık görüntüden sonrasını kaybedebilirsiniz. İkinci grup, büyük nesnelerdir: birkaç megabaytlık görsel ya da PDF, ağ üzerinden taşınan her baytın pahalı olduğu bir yerde önbellek değil gecikme üretir; onun yerine nesne depolama ve CDN kullanın. Üçüncü grup, ilişkisel sorguların konakçısıdır: çok tablolu raporlar, birleşimler ve karma filtreler Redis'te veri modeli değil, acı çağırır.

Anahtar tasarımı ayrımın görünür yüzüdür

Aynı komutları kullanan iki ekipten biri derli toplu, öteki kaosa dönüşür; fark anahtar isimlendirmesindedir. urun:42:detay gibi hiyerarşik isimler, urun:42:* deseniyle toplu temizliği mümkün kılar. Her anahtar bir TTL ile doğmalı; sonsuza kadar yaşamaya yazılmış veri, veritabanına değil Redis'e yazılır. maxmemory sınırı ve allkeys-lru gibi bir çıkarma politikası, önbelleğin bellek bütçesini uygulamanın değil sizin kararınız yapar.

Bir de popüler tuzağı anmak gerek: önbellek çığlığı. Binlerce istek aynı anda süresi dolmuş anahtarın ardına sıralanır, hepsi veritabanına döner. Çözüm basittir: yenilemeyi tek kilit arkasına alın ve TTL'lere rastgele pay ekleyin; hepsinin aynı saniyede ölmesini engellemek çoğu kez yeterlidir.

Sonuç olarak ayrım, bir tablo kadar sade: veri yeniden üretilebilir mi, kaybı tolere edilebilir mi ve hız kritik mi? Üçü de evet ise Redis'in kapısı açık. Şüphe varsa veritabanında bırakın; önbellek eklemek kolay, yanlış yere kurulmuş önbelleği sökmek zordur.

Bir son not: ayrım bir kez yapılır diye bir kural yoktur. Büyüyen sistemde bugün önbelleğe uygun olmayan veri, yarın desen değiştirebilir; tersi de geçerlidir. Yılda bir kez anahtar envanterini çıkarın, TTL'siz kalanları ve hiç okunmayan anahtarları listeyin. Ayrım sanatı, kuruluş günü verilen tek karar değil; düzenli bakım gibi sürdürülen bir alışkanlıktır.