Cache yalnızca sayfayı hızlandıran bir sihir değildir; neyin saklanacağı ve ne zaman silineceği yanlış seçilirse kullanıcıya eski veya tutarsız veri gösterilir. Bu rehberde yazılım cache stratejisini katmanlar, saklama adayları ve invalidation kararlarıyla ele alıyoruz.
Yazılım cache stratejisi çoğu ekipte “performansı artırır, her yere koy” cümlesiyle başlar. Gerçekte cache, okuma maliyetini düşürmek için verinin bir kopyasını başka bir yerde tutma kararıdır. Bu karar doğru kurulmazsa hız kazancı, bayat içerik, tutarsız sepet ve yanlış stok gibi operasyonel risklerle birlikte gelir.
Bu rehberde cache’i bir hız efsanesi olarak değil; ne saklanacağı, ne kadar süre tutulacağı ve ne zaman silineceği netleştirilmiş bir performans kararı olarak ele alıyoruz. Amaç, uygulamanızda hangi verinin kopyalanmaya değer olduğunu ve invalidation’ın nerede kırıldığını sade bir dille görünür kılmaktır.
Cache nedir, strateji neden gerekir?
Cache, pahalı veya yavaş bir kaynağa tekrar tekrar gitmemek için sonucun geçici kopyasını saklamaktır. Kaynak bir veritabanı sorgusu, harici API, hesaplanmış rapor, HTML parçası veya dosya olabilir. Kopya doğru ve güncel olduğu sürece yanıt süresi düşer; kopya geride kaldığında ise sistem “hızlı ama yanlış” hale gelir.
Strateji olmadan cache eklemek, genellikle üç hataya yol açar:
- Her şeyi saklamak: bellek şişer, tutarlılık bozulur.
- Hiçbir şeyi silmemek: TTL bitene kadar eski veri servis edilir.
- Yanlış katmanda saklamak: tarayıcı, CDN, uygulama ve veritabanı cache’i aynı işi farklı kurallarla yapar.
İyi bir yazılım cache stratejisi önce iş kuralını sorar: Bu veri bir saniye gecikse sorun mu olur, yoksa bir dakika eski kalsa sipariş mi bozulur?
Yazılım cache stratejisinde ne saklanır?
Saklanacak her aday, “yeniden üretme maliyeti” ile “değişme sıklığı” dengesinde değerlendirilir. Maliyet yüksek, değişim seyrekse cache güçlü adaydır. Maliyet düşük veya değişim çok sık ve kritikse cache ya kısa tutulur ya da hiç kullanılmaz.
Saklamaya uygun adaylar
- Referans ve katalog verisi: ülke listesi, kategori ağacı, sabit parametreler, nadiren değişen ürün özellik setleri.
- Ağır okuma sorguları: filtreli listeler, dashboard özetleri, rapor ön hesaplamaları; kaynak sorgu pahalıysa ve sonuç birkaç saniye-dakika gecikebiliyorsa.
- Harici API yanıtları: kur bilgisi, kargo fiyatı, stok sorgusu gibi dış servisler; kota ve gecikme riski yüksek olduğunda kontrollü cache işe yarar.
- Statik veya yarı statik içerik parçaları: menü HTML’i, SSS blokları, sık değişmeyen landing bileşenleri.
- Oturum ve yetki türevi (dikkatli): sık okunan ama kısa ömürlü oturum özeti; hassas alanlar ve yetki değişiminde anında invalidation şarttır. Oturum modeliyle ilgili kararlar için yazılım kimlik doğrulama ve yetkilendirme rehberine bakabilirsiniz.
Saklamaması veya çok kısa tutulması gerekenler
- Ödeme durumu, bakiye, stok rezervasyonu, sepet kilidi gibi anlık iş doğruluğu gereken alanlar.
- Kullanıcıya özel ve gizlilik içeren ham veriler; yanlış anahtar tasarımı sızıntı riski yaratır.
- Yazma sonrası hemen okunması beklenen “read-your-writes” senaryoları; kullanıcı kendi kaydını eski haliyle görürse güven kaybı oluşur.
- Rastgele veya tek seferlik sonuçlar; cache isabet oranı düşük kalır, karmaşıklık boşa gider.
Pratik kural: “Bu kopya yanlış olsa kullanıcı neyi yanlış yapar?” sorusuna net zarar çıkıyorsa, o veriyi uzun süreli cache’e koymayın.
Cache katmanları: nerede saklanır?
Tek bir “cache” yoktur. Katmanlar farklı amaç ve yaşam döngüsü taşır. Karıştırmak, silme işleminin bir katmanda çalışıp diğerinde bayat kopya bırakmasına yol açar.
- Tarayıcı / istemci cache: statik varlıklar ve bazı API yanıtları için. Kullanıcı kontrolündedir; sunucu tarafı invalidation her zaman hemen yansımaz.
- CDN / edge cache: coğrafi yakınlık ve bant genişliği için HTML, görsel, public API. Genel kitleye açık içerikte etkilidir; kişiselleştirilmiş sayfada dikkat ister.
- Uygulama / bellek cache: Redis, Memcached veya süreç içi bellek. İş mantığına en yakın katmandır; anahtar tasarımı ve TTL burada kritik hale gelir.
- Veritabanı sorgu / sonuç cache: motorun kendi plan ve buffer yapıları. Uygulama cache’inin yerine geçmez; darboğazı azaltır ama iş kuralı invalidation’ı sağlamaz.
E-ticaret katalog listesi CDN’de, stok sayısı uygulama cache’inde kısa TTL ile, ödeme sonucu ise cache’siz tutulabilir. Aynı ürün kartında bile alan bazlı ayrım gerekir. Katalog ve stok senaryolarında operasyon tarafını da düşünmek için çok depolu e-ticaret stok yönetimi yaklaşımıyla cache kurallarını birlikte okumak faydalıdır.
Ne zaman silinir? Invalidation yaklaşımları
“Ne zaman silinir?” sorusu, cache stratejisinin asıl zor kısmıdır. Saklamak kolaydır; doğru anda geçersiz kılmak zordur.
1) Süreye bağlı silme (TTL)
Her anahtara bir ömür verilir. Süre bitince kopya düşer veya yenilenir. Kurulumu basittir; “en fazla N süre eski olabilir” kabulü olan veriler için uygundur. Riski: süre dolmadan kaynak değişirse kullanıcı eski veriyi görür.
2) Olayla silme (event / write-through invalidation)
Veri yazıldığında ilgili cache anahtarları silinir veya güncellenir. Ürün güncellendiğinde ürün detayı ve ilgili liste anahtarları düşer. Doğruluk ihtiyacı yüksekse tercih edilir. Riski: hangi anahtarların etkilendiğini unutmak; bir liste anahtarı kalırsa bayat sonuç devam eder.
3) Sürüm / namespace ile toplu düşürme
Anahtarların önüne sürüm numarası veya namespace konur. Büyük bir değişiklik sonrası sürüm artırılır; eski anahtarlar dolaylı olarak ölü kalır. Toplu invalidation için pratiktir; bellek temizliği ayrı planlanmalıdır.
4) Lazy yenileme ve stampede koruması
Anahtar düştüğünde herkes aynı anda kaynağa hücum ederse veritabanı sarsılır. Tek üretici kilidi, kısa stale-while-revalidate veya kademeli TTL bu riski azaltır. “Silmek” kadar “yeniden doldurmayı sakinleştirmek” de stratejinin parçasıdır.
| Yaklaşım | Ne zaman uygun? | Başlıca risk |
|---|---|---|
| TTL | Az kritik, kabul edilebilir gecikmeli veri | Süre içinde bayat içerik |
| Olayla silme | Yazma sonrası doğruluk önemliyse | Eksik anahtar listesi |
| Sürüm / namespace | Toplu yenileme, yayın sonrası temizlik | Eski anahtarların bellekte birikmesi |
| Stale-while-revalidate | Kısa süre eski veri tolere edilirse | Kullanıcı kısa süre eski kopya görebilir |
Birçok sistemde hibrit model çalışır: kritik anahtarlar olayla düşer, ikincil özetler kısa TTL ile yaşar. “Her şeyi event ile sil” hedefi, anahtar haritası zayıfsa fiilen bozulur.
Tutarsız veri, bayat içerik ve yanlış invalidation
Cache’in en pahalı maliyeti milisaniye değil, yanlış kararın iş etkisidir.
- Bayat içerik: fiyat güncellendi, liste hâlâ eski fiyatı gösteriyor.
- Tutarsız görünüm: detay sayfası yeni, kategori listesi eski; kullanıcı aynı ürünü iki haliyle görür.
- Yanlış invalidation: tek ürün silinirken tüm katalog düşer (aşırı agresif) veya hiçbiri düşmez (aşırı pasif).
- Anahtar çakışması: kullanıcı A’nın sepet özeti, zayıf anahtar yüzünden kullanıcı B’ye sızar.
- Çok katmanlı gecikme: uygulama cache temizlendi, CDN hâlâ eski HTML servis ediyor.
Bu riskleri azaltmak için her cache kaydına üç etiket düşünün: sahiplik (public / kullanıcıya özel), kabul edilebilir eskilik, bağımlı anahtarlar. Bağımlılık listesi yoksa event invalidation kağıt üzerinde kalır.
KepezWeb ekipleri özel yazılım işlerinde cache’i “ekstra hız katmanı” olarak değil, veri sözleşmesinin parçası olarak tasarlamayı tercih eder. Performans ölçümüyle birlikte tutarlılık senaryoları da test planına girer; yalnızca yük testi yetmez. Performans tarafını ayrı ele almak isterseniz mevcut yazılım performans testi yaklaşımınızla cache hit/miss ve invalidation senaryolarını birlikte koşturmak daha sağlıklıdır.
Uygulanabilir bir cache karar çerçevesi
Aşağıdaki adımlar, yeni bir özellik veya darboğaz karşısında yazılım cache stratejisini somutlaştırır:
- Kaynağı adlandırın: hangi sorgu, API veya hesaplama pahalı?
- İş toleransını yazın: en fazla ne kadar eski veri kabul edilir? Hiç mi, saniyeler mi, dakikalar mı?
- Saklama birimini seçin: tüm sayfa mı, parça mı, alan mı? Mümkün olduğunca küçük ve yeniden kullanılabilir birim tercih edin.
- Anahtar tasarlayın: kaynak kimliği + filtreler + dil/para birimi + kullanıcı kapsamı. Belirsiz anahtar, yanlış veri demektir.
- Silme kuralını bağlayın: TTL mi, yazma olayı mı, ikisi mi? Olay listesini kod yorumunda değil, kontrol listesinde tutun.
- Katmanı seçin: public içerik edge’e, iş kuralı hassas veri uygulama cache’ine, anlık doğruluk gerekenler doğrudan kaynağa.
- Gözlemlenebilirlik ekleyin: hit oranı, miss sonrası kaynak süresi, invalidation sayısı, bayat şikayetleri. Ölçülmeyen cache yönetilemez.
- Geri alma planı koyun: feature flag veya config ile cache’i kapatabilmek, kriz anında hayat kurtarır.
Bu çerçeve özellikle yazılım geliştirme sürecinde erken konuşulmalıdır. Cache sonradan “üstüne yapıştırılan” bir optimizasyon olduğunda anahtar ve invalidation borçları hızla büyür. PHP/MySQL tabanlı özel sistemlerde sorgu maliyeti ile bellek cache dengesini kurmak için özel PHP/MySQL yazılım kararlarında da aynı soru seti geçerlidir.
Sıkça Sorulan Sorular
Cache her zaman performansı artırır mı?
Hayır. Düşük isabet oranlı, sık invalidation alan veya yanlış katmanda tutulan cache; bellek, karmaşıklık ve tutarsızlık maliyeti üretir. Önce darboğazı ölçün, sonra kopyalamaya değer veriyi seçin.
TTL mi yoksa olayla silme mi tercih edilmeli?
Verinin kabul edilebilir eskilik süresi net ve zarar düşükse TTL yeter. Yazma sonrası kullanıcının hemen doğru veriyi görmesi gerekiyorsa olayla silme veya hibrit model gerekir. Birçok ürün verisinde ikisi birlikte kullanılır.
Kullanıcı sepeti ve stok cache’lenmeli mi?
Sepet ve stok gibi alanlar genelde kısa ömürlü veya yazma sonrası anında düşen anahtarlarla yönetilir. Uzun TTL burada yanlış satış ve güven kaybı riski taşır. Public katalog ile kişisel sepet aynı politikaya bağlanmamalıdır.
Cache invalidation’ı nasıl test ederim?
Yalnızca “sayfa hızlı açılıyor mu?” yetmez. Veriyi güncelleyin; detay, liste, arama ve CDN katmanlarında eski kopyanın düşüp düşmediğini kontrol edin. Çok kullanıcılı senaryoda read-your-writes ve stampede davranışını da izleyin.
Uygulama cache’i ile CDN cache’i aynı şey midir?
Değildir. CDN coğrafi ve statik dağıtım için; uygulama cache’i iş verisi ve sorgu sonucu için çalışır. Birini temizlemek diğerini otomatik temizlemez. Invalidation planı katman katman yazılmalıdır.
Doğru yazılım cache stratejisi, hız vaadinden önce veri sözleşmesini netleştirir: ne saklanır, kim görür, ne kadar eskir, kim siler. Bu netlik yoksa cache teknik bir detay değil, sessiz bir hata kaynağına dönüşür. KepezWeb olarak web, e-ticaret ve özel yazılım projelerinde performans kararlarını iş riskiyle birlikte ele alıyoruz; cache tasarımını da aynı çerçevede değerlendiriyoruz. Uygulamanızda hangi verinin kopyalanmaya değer olduğunu ve invalidation haritanızı birlikte netleştirmek isterseniz teklif al sayfasından bize yazabilirsiniz.
