1. GİRİŞ

Caching, modern dağıtık sistemlerin ve web uygulamalarının performans optimizasyonunun temel taşlarından biridir. Doğru tasarlanmış bir cache katmanı, gecikmeleri düşürür, arka uç servislerinin yükünü hafifletir, veritabanı maliyetlerini azaltır ve kullanıcı deneyimini iyileştirir. Bugün, mikroservisler, cloud-native uygulamalar, mobil uygulamalar ve gerçek zamanlı hizmetler sayesinde veri erişim talepleri arttı; bu da caching stratejilerinin önemini daha da öne çıkarıyor.

Bu konu neden bugün önemli?

• Yüksek trafik uygulamalarında veritabanları hızla darboğaz oluşturur; cache ile okuma maliyeti düşürülür.
• Global kullanıcılar için edge caching ve CDN'ler gecikmeyi azaltır.
• Cloud maliyetleri optimize edilir: CPU, I/O ve egress ücretleri caching ile kontrol altına alınabilir.

Kimler için önemli?

• Backend geliştiriciler ve performans mühendisleri
• SRE/DevOps ekipleri
• Platform mühendisleri ve mimarlar

Hangi problemleri çözüyor?

• Yük altında veritabanı performansını koruma
• Kullanıcı gecikmelerini azaltma
• İşlem maliyetlerini ve kaynak kullanımını azaltma

2. KAVRAMSAL TEMELLER

2.1 Cache nedir?

Cache, sık erişilen verilerin daha hızlı erişilebilecek bir yerde (RAM, SSD, edge) geçici olarak saklanmasıdır. Cache'in amacı, asıl veri kaynağına yapılan maliyetli okumaları azaltmaktır. Caching, genelde tutarsızlık (stale data) riskini ve invalidation karmaşıklığını beraberinde getirir; bu yüzden bir tasarım problemi olarak ele alınmalıdır.

2.2 Cache seviyeleri

• In‑process (local) cache: Uygulama process içinde (ör. JVM/CLR heap) tutulan hızlı cache. Çok düşük latency sağlar fakat instance restart veya scale‑out ile state kaybolur.
• Distributed cache: Birden çok instance arasında paylaşılan cache (örn. Redis, Memcached). Yüksek erişilebilirlik ve paylaşılabilir state sağlar.
• Edge / CDN cache: Kullanıcıya en yakın noktada (edge) statik veya önbelleğe alınmış içerik sunar (örn. Cloudflare, Akamai, AWS CloudFront).
• HTTP cache: Web seviyesinde Cache‑Control, ETag, Last‑Modified gibi header'larla tarayıcı/CDN önbellekleme.

2.3 Cache metrikleri

• Hit ratio / hit rate
• Miss count / miss rate
• Eviction count
• Latency (p50/p95/p99) for cache ops
• Evicted keys by policy

3. NASIL ÇALIŞIR? — DESENLER VE TEKNİK DETAYLAR

3.1 Cache‑Aside (Lazy Loading)

Cache‑aside en yaygın desenlerden biridir. İşleyişi basittir: uygulama önce cache'e bakar; yoksa (cache miss) asıl veri kaynağından okur, cache'e yazar ve sonucu döner. Avantajı kontrolün uygulamada olmasıdır. Dezavantajları: cache stampede riski (çok sayıda client aynı anda miss alırsa), yazma tutarsızlıklarına karşı ekstra mekanizmalar gerekmesi.

3.2 Read‑Through / Write‑Through

Read‑through: Cache, bir middleware veya cache engine tarafından otomatik olarak veritabanından doldurulur; uygulama sadece cache'e erişir. Write‑through: Yazma işlemleri önce cache'e, sonra syncronously datastore'a yazılır. Bu model tutarlılığı artırır fakat yazma gecikmesini artırabilir.

3.3 Write‑Back (Write‑Behind)

Write‑back, yazma işlemini önce cache üzerinde tutup arka planda datastore'a asenkron yazma yapar. Performans avantajı vardır ancak veri kaybı riski (cache crash) ve kompleksity (write queue, retry logic) getirir.

3.4 Distributed locking ve cache coherence

Dağıtık cache kullanıldığında aynı anahtar üzerinde eş zamanlı güncellemeler conflict yaratabilir. Redlock (Redis) gibi distributed lock yaklaşımları veya optimistic locking ile tutarlılık sağlanabilir. Ancak dağıtık lock'ların dikkatli kullanılmaması performans sorunlarına yol açar. Her durumda eventual consistency ve idempotency mantığı önemlidir.

3.5 Cache invalidation stratejileri

Invalidation (geçersiz kılma) caching'in en zor problemidir. Yaygın stratejiler:

• Time‑based expiration (TTL): Her anahtar için yaşam süresi belirleyin.
• Event‑driven invalidation: Veri değiştiğinde pub/sub veya event bus ile ilgili cache anahtarlarını temizleyin.
• Versioning / Cache key versioning: Veri modeline versiyon ekleyerek eski cache'leri geçersiz sayma.
• Selective eviction: Değişen parent/child ilişkilerini izleyip ilgili anahtarları hedefli olarak temizleme.

3.6 Cache stampede (thundering herd) ve çözümleri

Popüler bir anahtarın TTL süresi dolduğunda çok sayıda client aynı anda veri kaynağına yönelirse cache stampede oluşur. Çözümler:

• Jittered TTL: TTL'leri rasgeleleştirerek expiry'lerin aynı anda olmamasını sağlama.
• Locking veya singleflight: İlk client veriyi alırken diğerlerini bekletme; Go'daki singleflight pattern buna örnektir.
• Hot cache prewarming / refresh ahead: TTL dolmadan popüler anahtarları yenileme.

3.7 Eviction politikaları

Cache kapasitesi sınırlı olduğunda hangi anahtarların atılacağı önemlidir. Yaygın politikalar:

• LRU (Least Recently Used)
• LFU (Least Frequently Used)
• TTL based eviction
• ARC, Random, FIFO gibi varyantlar

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Redis — Distributed in‑memory data structure store

Redis, key‑value yapı dışında list, set, sorted set, hash gibi veri tiplerini destekler. Ölçeklenebilirlik için clustering, persistence (RDB/AOF) ve replication özellikleri sunar. Sık kullanılan pattern'ler: cache‑aside, Bloom filter ile cache prefiltering, rate limiting ve session store.

4.2 Memcached — basit yüksek hızlı cache

Memcached, basit key‑value in‑memory cache olarak yüksek throughput sağlar. Veri tipleri sade olduğu için latency düşük; ancak persist, replication yetenekleri sınırlıdır. Genelde transient caching için tercih edilir.

4.3 CDN ve edge caching — Cloudflare, CloudFront, Akamai

Statik içerik (JS/CSS, imaj), API yanıtları ve SSR cache ile edge caching gecikmeyi ciddi şekilde azaltır. CDN'ler ayrıca cache key'leme, cache purging ve geolocation‑aware routing sağlar.

4.4 Varnish ve reverse proxy cache

Varnish gibi reverse proxy cache'ler HTTP katmanında cache sağlar; cache politikalarını VCL (Varnish Configuration Language) ile tanımlamak mümkündür. Dinamik sayfalar önbelleğe alındığında backend üzerinde ciddi yük azalır.

4.5 Application level caching örnekleri

ORM seviyesinde (EF Core, Hibernate second level cache), query result cache, fragment caching (view partials) veya computation caching (expensive calculations) gibi uygulama tarafı yaklaşımlar yaygındır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Okuma latency'sini düşürür ve throughput'u artırır.
• Veritabanı ve downstream servis yükünü azaltır.
• Maliyet optimizasyonu: daha az I/O ve işlem, daha düşük bulut faturası.

Sınırlamalar

• Cache invalidation zor bir problemdir — yanlış invalidation veri tutarsızlığına yol açabilir.
• Distributed cache işletimsel karmaşıklık ve ek maliyet getirir.
• Stale data: kullanıcıya eski veri gösterme riski ve bu durumun iş mantığına etkisi.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• Cache tier'lerini net ayırın: local cache (L1), distributed cache (L2), CDN (L3).
• Cache metriklerini (hit/miss, evictions, latency) toplayın ve SLA'lara göre alert'leyin.
• Cache key naming standardı oluşturun: namespace, version ve purpose bilgisi içersin (örn. service:entity:v1:id).

Performans optimizasyonu

• Hot key'leri tespit edip özel handling uygulayın (pinning, prewarm).
• Compression kullanırken CPU maliyetini göz önünde bulundurun; trade‑off değerlendirin.
• Connection pooling, pipelining ve client lib optimizasyonları ile latency azaltın.

Güvenlik

• Sensitif verileri cache'e koymaktan kaçının; gerekiyorsa encryption at rest ve access controls uygulayın.
• Redis gibi servisleri VPC/private network içinde çalıştırın; authentication (ACL, AUTH) ve encryption kullanın.

Observability

• Trace ve logs ile cache access flow'larını korelasyonlayın; cache miss root cause analizini kolaylaştırın.
• Heatmaps ve top‑N keys ile hangi anahtarların en fazla etkisi olduğunu görün.

8. SIK YAPILAN HATALAR

• Her şeyi cache'lemek — bazı veriler cache için uygun değildir; cache overhead'i artırır.
• Cache invalidation'ı ihmal etmek — stale veri iş mantığını bozar.
• Hot key'leri göz ardı etmek — tek bir anahtar cluster'ı zorlayabilir.
• Uygulama logikini cache'e bağımlı hale getirmek — cache olmadan sistem çökmesine yol açar.

9. GELECEK TRENDLER

1. Adaptive / AI‑driven caching: Telemetry'e dayalı adaptive TTLler, otomatik hot key prewarming ve cache policy önerileri.
2. Edge compute ile tight integration: CDN ve edge functions'ın stateful caching ile birleşmesi—daha akıllı edge cache kararları.
3. Hybrid transactional caches: Cache ile veri tutarlılığını garanti ederken performansı koruyan yeni konsensüs tabanlı yaklaşımlar.
4. Serverless friendly caches: Cold start ve ephemeral env'lerde etkili caching stratejileri gelişecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Hangi veriler cache'e uygun değildir?

   Çok sık değişen (high churn) veya tutarlılığın kritik olduğu transactional veriler genelde cache için uygun değildir. Finansal transfer gibi gerçek zamanlı kesin doğruluk gerektiren veriler cache'ten kaçınılmalıdır.

2. 2. Cache‑aside mı yoksa write‑through mu tercih etmeliyim?

   Genelde okuma‑ağırlıklı workload'larda cache‑aside basit ve etkili bir seçimdir. Tutarlılığın çok önemli olduğu senaryolarda write‑through tercih edilir. Performans gereksinimleri, tutarlılık ve operasyonel karmaşıklık kararınızı etkiler.

3. 3. Redis mi Memcached mi?

   Redis daha zengin veri tipleri, persistence ve replication özellikleri sunar; Memcached daha basit ve yüksek throughput sağlar. İhtiyacınıza göre seçim yapın: basit transient cache için Memcached, complex use‑cases için Redis.

4. 4. Cache stampede'i nasıl önlerim?

   Jittered TTL, singleflight/locking, prewarming ve refresh‑ahead stratejileri ile önleyebilirsiniz. Önemli anahtarlar için önceden yenileme (refresh) uygulayın.

5. 5. Cache key design nasıl olmalı?

   Namespace, service adı, entity tipi ve versiyon içeren standart bir şema kullanın (örn. orders:byId:v2:1234). Bu, invalidation ve debugging süreçlerini kolaylaştırır.

6. 6. CDN ile dynamic content nasıl cache'lenir?

   Edge caching, cache key'leme (vary headers, query string normalize), stale‑while‑revalidate ve origin shield gibi tekniklerle dynamic content'in etkili önbelleklemesini gerçekleştirebilirsiniz.

7. 7. Cache metrikleri için hangi eşikler önemlidir?

   Hit rate hedeflerinizi iş ihtiyaçlarına göre belirleyin (örn. %90+). Eviction rate, p99 latency ve cache availability de SLA metrikleriniz olmalı.

8. 8. Cache'i test ve doğrulamak için ne yapmalıyım?

   Load test ile cache davranışını simüle edin, fault injection ile node kaybı senaryolarını test edin ve canary rollouts ile invalidation stratejilerini doğrulayın.

Anahtar Kavramlar

Cache‑aside

Uygulamanın önce cache'e baktığı, miss durumunda datastore'dan okuyup cache'e yazdığı desen.

Write‑through / Write‑back

Yazma politikaları: syncronous write vs async write.

Cache stampede

TTL expiry sonrası çok sayıda isteğin aynı anda backend'e yönelmesi durumu.

LRU / LFU

Cache eviction politikaları: en az kullanılan veya en az sıklıkla kullanılan anahtarların atılması.

Edge cache

CDN veya edge node'larda tutulan cache; kullanıcıya yakın sunulur.

Öğrenme Yol Haritası

1. 0–1 ay: HTTP caching (Cache‑Control, ETag), temel in‑memory cache kavramlarını öğrenin ve uygulamada MemoryCache veya local cache kullanın.
2. 1–3 ay: Redis/Memcached ile distributed caching uygulamaları geliştirin; cache‑aside, read‑through desenlerini uygulayın ve ölçün.
3. 3–6 ay: CDN/edge caching, reverse proxy (Varnish) ve cache invalidation stratejilerini öğrenin; load & chaos testing yapın.
4. 6–12 ay: Adaptive caching, hot key handling, distributed locks, persistence & clustering konularında derinleşin ve production scale deneyimi edinin.