Cache Nedir? Bir Uygulamayı Aynı İşi İki Kez Yapmaktan Kurtaran Mekanizma

Bir SaaS panelinin ana sayfasını her açtığında, arka planda aynı veritabanı sorgusu yeniden çalışıyor olabilir — aynı kullanıcı, aynı gün, aynı sonuç, ama sunucu her seferinde sıfırdan hesaplıyor. Cache nedir sorusunun en kısa cevabı da tam burada saklı: bir işlemin sonucunu bir kere hesaplayıp bir kenara koymak, aynı soru tekrar geldiğinde onu yeniden hesaplamak yerine kenardaki hazır cevabı vermek. Kulağa basit geliyor, ama bir uygulamanın 200 milisaniyede değil 5 milisaniyede yanıt vermesinin, ya da bir sunucunun on kat daha az yük altında aynı trafiği karşılamasının sırrı genelde tam olarak bu.

##Cache Nedir, Aslında Ne Yapıyor?

Her cache sistemi aynı üç adımı işletir: önce 'bu cevap elimde var mı' diye bakar (buna cache hit denir), varsa sonucu doğrudan döner; yoksa (cache miss) gerçek işi yapar — veritabanına sorgu atar, bir API çağırır, ağır bir hesaplama yapar — sonucu hem kullanıcıya döner hem de bir sonraki sefer için bir kenara, genellikle bir anahtar-değer (key-value) yapısında saklar. Anahtar genelde 'bu isteği benzersiz kılan şey' olur: bir ürün ID'si, bir kullanıcı ID'si, bir URL. Bir e-ticaret sitesinde 'urun-482' anahtarıyla saklanan bir cache girdisi, o ürün sayfasına gelen bin farklı ziyaretçi için veritabanına bin kez değil bir kere gider; geri kalan 999 istek doğrudan bellekten, cache'ten karşılanır. Bu oranı takip etmenin de bir ölçütü var: cache hit oranı, yani isteklerin yüzde kaçının cache'ten karşılandığı. İyi ayarlanmış bir sistemde bu oran genelde %80'in üzerinde olur; düşükse ya TTL çok kısa tutulmuştur ya da yanlış, nadiren tekrar eden veri cache'lenmeye çalışılıyordur.

##Cache'in Çalıştığı Katmanlar

Cache tek bir yer değil; bir uygulamanın neredeyse her katmanında ayrı ayrı devreye girer, ve genelde bunların birkaçı aynı sistemde birlikte çalışır:

• ▸Tarayıcı cache'i: Bir kere indirdiğin bir resmi, CSS ya da JS dosyasını tarayıcın diskte tutar, aynı siteye ikinci girişte tekrar indirmez.
• ▸CDN (içerik dağıtım ağı) cache'i: Statik dosyaları kullanıcıya coğrafi olarak yakın bir sunucuda önceden tutar — Cloudflare, Fastly gibi hizmetler bunu yapar.
• ▸Uygulama katmanı cache'i: Redis veya Memcached gibi araçlarla, hesaplanması pahalı sonuçları (bir API cevabı, hazırlanmış bir rapor) bellekte tutmak.
• ▸Veritabanı sorgu cache'i: Aynı SQL sorgusunun sonucunu veritabanının kendisinin kısa süreliğine saklaması.
• ▸İşletim sistemi / disk cache'i: Sık okunan dosyaları diskten değil doğrudan RAM'den okumak.

Hangi katmanın kullanılacağı, verinin ne kadar sık değiştiğine ve kimin göreceğine bağlı. Tarayıcı cache'i statik dosyaları, CDN görselleri, Redis ise dinamik ama sık istenen verileri karşılar — bir üretim sisteminde bu katmanlar genelde aynı anda, birbirini tamamlayarak çalışır.

##Gerçek Bir Örnek: Bir Ürün Sayfasının Cache Öncesi ve Sonrası

Orta ölçekli bir e-ticaret sitesini düşün: günde 50 bin ürün sayfası görüntülemesi var, her görüntülemede sunucu veritabanına gidip ürün bilgisini, stok durumunu, fiyatı ve ilgili ürünleri ayrı ayrı sorguluyor — toplam 4-5 sorgu, ortalama 180-250 milisaniye. Yoğun saatlerde veritabanı CPU'su %80'lerin üstüne çıkıyor, sayfa açılışı gözle görülür yavaşlıyor. Çözüm karmaşık değil: ürün verisi dakikada birkaç kez değil günde birkaç kez değişiyor (stok ve fiyat güncellemeleri dışında), yani her istek için veritabanına gitmenin bir anlamı yok. Redis'e 'urun-482' gibi bir anahtarla, o ürünün tüm sayfa verisini 5 dakikalık bir süreyle (TTL) yazıyorsun. İlk istek yine veritabanına gidiyor ve sonucu Redis'e yazıyor; ondan sonraki 5 dakika boyunca gelen tüm istekler doğrudan Redis'ten, 3-8 milisaniyede yanıt buluyor. Sonuç: aynı trafikte veritabanı yükü büyük ölçüde düşüyor, sayfa açılış süresi gözle görülür kısalıyor, en yoğun kampanya günlerinde bile veritabanı devrilmiyor. Stok gibi anlık değişmesi gereken bir veri varsa, o kısmı cache dışında tutup ayrı, cache'lenmemiş bir uçtan çekmek — ya da stok güncellendiğinde ilgili cache girdisini elle temizlemek (invalidate etmek) — genelde çözüm oluyor.

##Cache Invalidation: İşin Asıl Zor Kısmı

Bilgisayar biliminde sık tekrarlanan bir söz var: 'İki zor şey vardır: cache invalidation ve isimlendirme.' Şaka gibi dursa da gerçek bir sorunu anlatıyor — cache'i doldurmak kolay, ama içindeki veri bayatladığında (kaynak veri değiştiğinde) onu doğru zamanda temizlemek zor. Dört yaygın strateji var:

• ▸TTL (time-to-live): Veriyi belirli bir süre sonra otomatik geçersiz say. Kurulumu basit ama süre boyunca bayat veri gösterme riski var.
• ▸Event-based invalidation: Kaynak veri değiştiğinde (ör. fiyat güncellendiğinde) ilgili cache anahtarını o an sil. Daha doğru sonuç verir ama her yazma işleminde ekstra kod ister.
• ▸Write-through cache: Veri veritabanına yazılırken aynı anda cache de güncellenir, böylece hiç bayat an olmaz — ama yazma işlemi biraz yavaşlar.
• ▸Stale-while-revalidate: Bayat veriyi hemen göster, arka planda taze veriyi getir ve bir sonraki istek için cache'i güncelle — kullanıcı hiç beklemez.

Pratikte en çok baş ağrıtan senaryo şu: TTL'i çok uzun tutarsan kullanıcı güncel olmayan bir fiyat ya da tükenmiş bir stok görebilir — bu güven sorunu yaratır. Çok kısa tutarsan cache'in getirdiği fayda neredeyse sıfırlanır, veritabanı yine sürekli çalışır. Doğru süre veriye göre değişir: bir blog yazısı için saatler makul, bir stok sayacı için saniyeler bile uzun olabilir. Kritik veri için event-based invalidation'ı TTL ile birlikte kullanmak — yani hem bir üst sınır koymak hem değişiklik anında elle temizlemek — çoğu gerçek projede en dengeli yaklaşım.

##Cache Ne Zaman Riskli ya da Gereksiz Olur?

Cache her yerde iyi fikir değil. Bir banka hesap bakiyesini, bir ödeme durumunu ya da kişiye özel, sık değişen bir veriyi cache'lemek riskli — kullanıcı yanlış ya da eski bir rakam görebilir, bu da ciddi bir güven sorunu yaratır. Aynı sorgunun neredeyse hiç tekrar edilmediği durumlarda (her kullanıcı için farklı, tek seferlik bir rapor gibi) cache eklemek fayda getirmez, sadece karmaşıklık ve bir bakım yükü ekler. Ve küçük, henüz gerçek bir performans sorunu yaşamayan bir uygulamada baştan cache katmanı kurmak da klasik bir erken optimizasyon hatası — önce gerçek darboğazı ölç (hangi sorgu, hangi endpoint yavaş), cache'i tam oraya koy. Rastgele her yere Redis eklemek performansı değil, sadece kod karmaşıklığını artırır.

##Cache Stampede: Binlerce İsteğin Aynı Anda Veritabanına Çarpması

Cache'in kendi başına yarattığı ilginç bir sorun var: cache stampede (ya da 'thundering herd'). Çok istenen bir cache anahtarının süresi (TTL) dolduğu an, o saniyede gelen yüz, bin isteğin hepsi aynı anda 'cache'te yok' cevabını alır ve hepsi birden veritabanına aynı sorguyu atar — normalde bir isteğin karşılayacağı yükü, bir anda yüzlerce eşzamanlı sorgu olarak veritabanının üstüne boşaltır. Yoğun trafikli bir sistemde bu, cache'in önlemesi gereken tam o veritabanı çökmesini tetikleyebilir. Yaygın çözüm: 'lock' ya da 'single-flight' deseni — ilk isteğin veritabanına gitmesine izin ver, aynı anahtar için gelen diğer isteklerin ilk isteğin sonucunu beklemesini sağla, veritabanına aynı sorguyu tekrar tekrar atmasınlar. Bir diğer yaklaşım, TTL'e küçük rastgele bir sapma eklemek (jitter) — böylece binlerce anahtar aynı milisaniyede değil, dağılarak sona erer.

##Sık Sorulan Sorular

>Redis mi Memcached mi kullanmalıyım?

Çoğu yeni proje için Redis daha mantıklı seçim: basit key-value'nun ötesinde liste, set, sayaç gibi veri yapıları sunar, isteğe bağlı olarak diske de yazabilir (Memcached tamamen bellekte, sunucu yeniden başladığında her şey sıfırlanır). Memcached'in avantajı daha basit olması ve çok yüksek, saf key-value yükünde bir miktar daha hafif kalması — ama pratikte bu fark çoğu projede hissedilmiyor. Yeni bir sistem kuruyorsan Redis'le başlamak, ileride ihtiyaç duyacağın esnekliği baştan sağlar.

>Cache süresi (TTL) ne kadar olmalı?

Sabit bir kural yok, veriye göre değişir. Genel bir başlangıç noktası: nadiren değişen veri (kategori listesi, statik sayfa içeriği) için saatler-günler; orta sıklıkta değişen veri (ürün fiyatı, stok özeti) için dakikalar; sık değişen veri (canlı bir sayaç, bildirim listesi) için saniyeler ya da hiç cache kullanmamak. Yanlış tarafa düşersen bile kurtarma yolun var: TTL'i kısa tutup event-based invalidation eklemek, çoğu zaman en güvenli orta yol.

>Cache kullanmak sunucu maliyetini gerçekten düşürür mü?

Genelde evet, ama otomatik değil. Doğru yerde kullanılan bir cache, veritabanı sunucusunu daha küçük tutmana ya da onu büyütme ihtiyacını ertelemene yardımcı olur — bir Redis instance'ı, ölçeklenmiş bir veritabanından genelde çok daha ucuzdur. Ama cache'in kendisi de bir kaynak: bellek, işletim maliyeti ve invalidation mantığının bakımı gerektirir. Trafiği az, sorgusu zaten hızlı olan bir sistemde cache eklemek maliyeti düşürmez, tam tersine gereksiz bir bileşen ekler.

>Cache her zaman uygulamayı hızlandırır mı?

Hayır, doğru kurulmadığında tam tersi de olabilir. Cache'e bakmak, yazmak ve gerektiğinde geçersiz kılmak da bir iş — çok basit, zaten hızlı bir sorguya cache eklemek, faydasından fazla ek yük (network gidiş-gelişi, invalidation mantığı) getirebilir. Cache'in gerçekten fark yarattığı yer, aynı sonucun tekrar tekrar, ucuza hesaplanamayacak kadar pahalı bir işlemle üretildiği durumlar — basit bir toplama işlemini cache'lemenin bir anlamı yok, ama beş tabloyu birleştiren bir rapor sorgusunu cache'lemenin ciddi anlamı var.

Cache, doğru yerde kullanıldığında bir uygulamanın hem hızını hem de sunucu maliyetini ciddi şekilde değiştirebilen, ama yanlış kurulduğunda sessizce bayat veri gösteren bir mekanizma. Bir sistemin neresinin yavaş olduğunu, neyin ne sıklıkla değiştiğini anlamadan cache eklemek yerine, önce darboğazı ölçmek her zaman daha sağlıklı bir başlangıç. Benzer bir performans sorununu konuşmak istersen /contact üzerinden yazabilirsin.