CDN Cache Invalidation Stratejileri: Hız ve Doğruluk Dengesi

Web performansında CDN kullanmak artık standart; asıl farkı yaratan ise cache invalidation stratejisidir. Yanlış kurulduğunda iki tip problem görürsün: ya kullanıcı eski içeriği görmeye devam eder (stale content), ya da sık invalidation nedeniyle CDN hit oranı düşer ve origin maliyeti artar. Doğru çözüm tek bir ayar değil, içerik tipine göre ayrı politika tanımlamaktır.

Bu yazıda "hızlı ama doğru" içerik dağıtımı için pratik bir çerçeve kuracağız.

Önce İçeriği Sınıflandır

Tek TTL ile tüm siteyi yönetmek hatalıdır. Genelde üç içerik sınıfı yeterlidir:

1. Statik versiyonlu asset'ler (app.4f2a1.js, style.a9c2.css)
2. Yarı dinamik sayfalar (blog listesi, kategori sayfaları)
3. Kritik dinamik içerikler (fiyat, stok, kampanya gibi anlık doğruluk isteyen veriler)

Client
  |
  v
CDN Edge ---- cache hit? ----> yes -> response
  | no
  v
Origin (API/App)
  |
  +-- Cache-Control policy by content type

Strateji 1: Versioned Asset + Uzun TTL

Frontend build çıktılarında hash'li dosya adı kullanıyorsan en güvenli model budur:

• Cache-Control: public, max-age=31536000, immutable
• Dosya adı değişmedikçe içerik değişmez.
• Yeni release'te yeni hash gelir, invalidation gerekmez.

Bu yaklaşım hem cache hit oranını yükseltir hem de global dağıtımda tutarsızlık riskini azaltır.

Strateji 2: HTML İçin Kısa TTL + SWR

HTML dokümanlar genellikle daha hızlı güncellenir. Önerilen örnek:

Cache-Control: public, max-age=60, stale-while-revalidate=300

Bu modelde kullanıcı çoğunlukla hızlı yanıt alır, edge arka planda içeriği tazeler. Trafik dalgalanmalarında origin'i korur.

Strateji 3: Tag/Path Bazlı Purge

İçerik yönetim sistemi (CMS) kullanan ekiplerde "tüm cache'i boşalt" refleksi pahalıdır. Bunun yerine:

• Yazı güncellenince yalnızca ilgili path'ler purge edilir.
• Kategori sayfası gibi bağlı sayfalar etiket (tag) ile birlikte temizlenir.

Post updated: /blog/a
Purge:
 - /blog/a
 - /blog
 - /kategori/yapay-zeka
Do NOT purge:
 - /hakkimizda
 - /iletisim
 - unrelated assets

Bu yöntem, doğruluğu korurken hit ratio kaybını sınırlı tutar.

Anti-Pattern: Global Purge

Her deploy sonrası tüm cache'i boşaltmak kısa vadede "temiz çözüm" gibi görünür ama üretimde şu sonuçları doğurur:

• Trafik origin'e yığılır.
• TTFB artar.
• Ani maliyet yükselişi olur.
• Peak saatlerde kesinti riski büyür.

Global purge yalnızca istisnai ve kritik güvenlik durumlarında düşünülmelidir.

Gözlemlenebilirlik Olmadan Yönetilemez

Doğru invalidation stratejisinin çalıştığını anlamak için metrik şart:

• CDN hit ratio
• Origin request rate
• P95 TTFB
• Purge sonrası yayılım süresi
• 4xx/5xx trendi

Metriklerle birlikte release notlarına "hangi path/tag purge edildi" bilgisini eklemek, incident analizinde ciddi zaman kazandırır.

Yayın Sürecine Entegre Et

Sağlam bir CI/CD adımı şu sırayı izler:

1. Build -> hash'li asset üret
2. Upload -> CDN/origin'e yükle
3. Deploy -> yeni manifest yayınla
4. Targeted purge -> sadece gerekli path/tag
5. Smoke test -> kritik URL ve cache header kontrolü

Bu akış, "hızlı rollout + kontrollü invalidation" dengesini pratikte uygulanabilir hale getirir.

Sonuç

CDN performansının asıl sırrı sadece edge'e yakın olmak değil, cache geçersiz kılmayı doğru modellemektir. Versioned asset'lerde uzun TTL, HTML'de SWR, içerik güncellemelerinde hedefli purge yaklaşımı birlikte kullanıldığında hem kullanıcıya hızlı yanıt verilir hem de içerik doğruluğu korunur. Üretimde sürdürülebilir bir performans istiyorsan invalidation stratejisini release sürecinin çekirdeğine koymalı, metriklerle sürekli kalibre etmelisin.