CDN + Prerender Çakışması: Oda İçeriği Güncellenince Yanlış Sayfanın Önbelleğe Düşmesini Önleme

Chat sitelerinde oda içerikleri sık sık değişiyorsa ve hem CDN edge cache hem de prerender cache aynı anda devredeyse, bazen kullanıcılar ya da Googlebot beklenmeyen bir sürümle karşılaşabiliyor. Kısacası şu problemle uğraşıyorsunuz: Chat sitesinde CDN önbellekleme ile prerender arası çakışma: oda içerikleri güncellenince yanlış sayfa önbelleğe düşerse ne yapılır? Asıl mesele, “hangi katman neyi hangi anahtarla saklıyor ve invalidation/purge sırası nasıl olmalı?” sorusunu netleştirmek.

Bu yazıda, özellikle “oda slug’i aynı ama içerik değişiyor” gibi durumlarda yanlış HTML’in edge’e ya da prerender snapshot’ına düşmesini engelleyecek mimari kararları, baştan sona bir olay akışıyla ele alacağım. Hedefim; teknik ekibinizin incident süresini kısaltırken SEO ve performans hedeflerinizi de korumanıza yardımcı olmak.

Sorun Senaryosu ve Belirti Semptomları

En tipik şikâyet şu formatta gelir: Oda içeriği güncellendi, ancak bazı kullanıcılar eski oda açıklamasını, eski mesaj özetini ya da hatta bambaşka bir odaya ait başlık/meta açıklamasını görebilir. Bu bazen “sporadik” gibi görünür; bazen de belirli bölgelerde ya da belirli bot kullanıcı ajanlarında daha net fark edilir.

Semptomları doğru sınıflandırmak teşhisi hızlandırır. Çünkü prerender ile CDN’nin aynı anda karıştığı senaryolarda, düzeltmenin nerede yapılacağı (prerender mı edge mi?) çoğu zaman belirtilerle anlaşılır.

• Yanlış oda içerik gösterimi: Aynı URL’de farklı içerik beklenirken başka oda slug’inin snapshot’ı gelir.
• Eski içerik dönmesi: Oda güncellemesi sonrası belirli süre boyunca güncel metin yerine eski metin görünür.
• Geçersizlenme (invalidation) “başarılı görünüyor” ama etki yok: Prerender invalidation API çağrısı döner, fakat edge hâlâ eski sayfayı basmaya devam eder.
• Googlebot’ta daha belirgin etkiler: Prerender tetiklendiğinde bot’un gördüğü HTML farklı olabilir; bu da snippet ve index davranışını etkiler.

Terminoloji: Prerender cache, CDN edge cache, invalidation vs purge

İlk adım kavramsal ayrımı doğru yapmak: prerender cache, bot’un ya da SSR yerine render edilen HTML üretiminin “snapshot”larını saklar. CDN edge cache ise HTTP yanıtlarını PoP’lerde (edge lokasyonlarında) cache’ler. Bu iki katman; TTL, varsayım ve davranış olarak birbirinden bağımsız çalışabilir.

“Invalidation” genellikle bir cache objesinin ilgili anahtar/etiket setine göre geçersizleştirilmesini ifade eder. “Purge” ise çoğu CDN’de edge üzerindeki cache objesinin doğrudan temizlenmesi ya da revalidation’ın zorlanması anlamına gelir. Prerender tarafında invalidation başarılı görünse bile, CDN tarafında purge yapılmazsa edge hâlâ eski HTML’yi servis edebilir.

Kök Neden Haritası

Yanlış sayfanın önbelleğe düşmesi çoğunlukla “cache key tasarımı” ve “event sırası” hatalarının birleşiminden çıkar. Aşağıdaki kök neden haritası, chat sitesi oda güncellemelerinde en sık gördüğümüz mekanizmaları özetler.

Görünür Belirti	Muhtemel Kök Neden	İlk Kontrol Noktası
Oda slug aynı ama açıklama eski geliyor	CDN cache key sadece slug’e göre (payload/etag varyansı yok)	CDN cache key & varyant/etag kullanımı
Prerender invalidation çağrısı var ama bot hâlâ eski HTML görüyor	CDN purge yapılmadığı için edge snapshot hâlâ dönüyor	Invalidation→purge sırası ve mapping

Haritanın diğer sık dalları: varyans eksikliği (Vary header’ı yok), yanlış cache-control veya surrogate-control header’ları, event sırası (prerender önce güncelleniyor ama edge sonra), etiket uyumsuzluğu (prerender tag ile CDN purge tag aynı değil) ve auth/etiketli içeriklerde cookie etkisinin cache key’e yansımaması.

Başlangıç Teşhisi: Hangi katmanda problem var? (edge mi prerender mı?)

Her incident’i “hepsi cache” diyerek çözmek hem zaman alır hem de maliyetli olur. Bunun yerine ilk teşhisi hızlı yapın: aynı URL için farklı istemci tipleriyle karşılaştırın. Örneğin normal kullanıcı tarayıcısı, bot kullanıcı ajanı simülasyonu ve doğrudan origin’e giden istekler.

Pratikte şu soruya cevap arayın: Kullanıcı eski içeriği mi görüyor, yoksa sadece bot mu? Kullanıcı görüyorsa büyük olasılıkla CDN edge cache; sadece bot görüyorsa prerender cache daha güçlü ihtimaldir. İkisi de etkileniyorsa genellikle both-caches eşleşmesi ve purge sırası problemi birlikte vardır.

Doğru Cache Key Tasarımı (URL parametreleri, canonical, dil/locale, auth durumu, room slug/id)

Cache key tasarımı, bu problemin kalıcı çözümünde kritik rol oynar. Oda slug’i aynı kalırken içerik değişiyorsa, cache key yalnızca slug’e bakarak “oda değişmedi” varsayımı yapmamalı. Bunun yerine, içerik sürümünü ifade eden bir varyant ya da imza bilgisi eklemelisiniz.

Örnek 1: Oda slug’i aynı kalırken içerik değişiyor; CDN cache key sadece slug’e göre tutuluyorsa eski içerik döner—çözüm: varyant/payload/etag yaklaşımı.

Pratikte bunu birkaç farklı yolla yapabilirsiniz:

1. Versiyonlu payload: Oda içeriğinin “version” alanını (ör. room_revision) response içine ve/veya cache key’e taşıyın.
2. ETag/Content hash: Oda içeriği değişince bir hash üretin; CDN cache key veya ilgili varyant parametresi bu hash’i yansıtsın.
3. Varyant parametresi: slug sabit kalabilir ama “renderVersion” veya “templateVersion” gibi bir parametre key’i etkileyebilir.

Dil/locale; kullanıcı arayüzünde fark yaratıyorsa cache key’e locale eklemek gerekir. Auth durumuna bağlı içeriklerde (ör. üye olmayan kullanıcıya teaser gösterme) cookie tabanlı varyantı veya “public vs private render” ayrımını düşünün. Aksi halde aynı URL aynı key ile hem teaser hem tam içeriğin snapshot’unu paylaşabilir.

Invalidation/Purge Stratejisi: Oda güncelleme akışı (event → prerender invalidation → CDN purge) ve sıralama mantığı

İlk prensip şu: Oda güncellemeleri bir “event” gibi ele alınmalı ve cache katmanlarının temizleme sırası belirli olmalı. Yanlış sırayla yapılan purge, edge’in yeni veriyi origin’den çekmeden eski snapshot’u tekrar servis etmesine sebep olabilir.

Örnek 2: Prerender etiket invalidation başarılı ama CDN purge yapılmadığı için edge hâlâ eski snapshot basar—çözüm: purge sıralaması ve etiket→purge mapping.

Bu yüzden önerilen akış genellikle şöyle işler:

• 1) Origin verisini atomik güncelle: Room içeriğini (DB + search index/SSR template) tek bir transaction veya publish adımıyla “tutarlı” duruma getirin.
• 2) Prerender invalidation: Prerender tarafında oda etiketleri veya URL pattern’leriyle snapshot’u geçersizleştirin.
• 3) CDN purge: CDN edge cache objelerini ilgili cache key/etiket setine göre purge edin.
• 4) Revalidation tetikleme (opsiyonel): Trafiği yüksek odalarda, bot/user geleceği anda “ilk istek origin’e gitsin” diye kontrollü warm-up yapılabilir.

Etiket→purge mapping burada kritik. Prerender tarafında kullandığınız tag ile CDN’nin purge edebildiği tag/kural seti birebir aynı değilse, invalidation başarılı görünse bile edge’de doğru nesne temizlenmeyebilir. Bu nedenle mapping’i dokümante edin ve mutlaka test edin.

TTL ve Stale-Control: kısa TTL, soft purge vs hard purge; serving stale while revalidating riskleri

TTL, “yanlış içeriğin ekranda kalma süresini” belirler. Oda içerikleri sık değişiyorsa özellikle prerender HTML ve oda meta alanları için daha kısa TTL düşünün. Ancak TTL’yi kısaltmak tek başına her zaman yeterli olmaz; stale while revalidating gibi mekanizmalar yanlış içerik penceresini istemeden uzatabilir.

Soft purge veya stale serving; ilk etapta performans avantajı sağlayabilir. Fakat şu riski taşır: oda güncellendiğinde origin yeni veriyi bilirken, edge “stale”yi bir süre boyunca yeni revalidation gelene kadar servis etmeye devam edebilir. Bu da kullanıcıya eski HTML etkisini sürdürür.

Bu yüzden karar matrisi oluşturun: SEO açısından kritik alanlar (başlık, açıklama, canonical bileşeni) güncelleniyorsa hard purge gereksinimi artar. Tam içerik ağırsa soft yaklaşım uygulanabilir; fakat prerender snapshot’unda noindex/robots dışı durumların etkileşimi de ayrıca gözden geçirilmelidir.

Varyans ve Header Stratejileri (Cache-Control, Surrogate-Control, Vary, Accept-Encoding, cookie/auth etkisi)

HTTP cache header’ları yalnızca performans için değil, yanlış içerik karışmasını önlemek için de belirleyicidir. Burada iki temel çifti ayırt etmek gerekir: Cache-Control tarayıcıya ve standart cache katmanlarına dair sinyalleri etkiler; Surrogate-Control ise genelde CDN/edge davranışı için kullanılır.

Örnek 3: Cache-Control header’ı prerender yanıtında farklı; Googlebot’a eski HTML gider—çözüm: header tutarlılığı ve template doğrulaması.

Bu tip senaryolarda, prerender tarafından üretilen HTML’in header’ları ile origin veya normal SSR yanıtının header’ları arasında fark varsa, CDN yanlış nesneyi cache’leyebilir ya da revalidation davranışı beklenmedik şekilde çalışabilir.

Ek olarak Vary header’ı özellikle kritik bir araç. Aşağıdaki varyant boyutlarını doğru belirtmezseniz tek bir cache key oluşur ve farklı kullanıcı durumları aynı objeyi paylaşır:

• Accept-Encoding (gzip/br) — sık karşılaşılır
• Locale (dil) veya segment
• Auth/cookie durumuna bağlı render farkları
• Etiket/label’a göre render (ör. “moderated state”, “featured”)

Bots/Googlebot Özel Durumlar: prerender tetiklenme koşulları, noindex ile etkileşim

Prerender’ın devreye girme koşullarını güvenli şekilde kurmalısınız. Googlebot benzeri crawler’lar için prerender tetikleme sinyali; sadece kullanıcı ajanı ile değil aynı zamanda response cache header’ları ve noindex kurallarıyla uyumlu olmalıdır.

Özellikle “private room” veya “moderatör state” gibi bazı oda varyantları noindex edilmeliyse, prerender HTML’de bu noindex sinyallerinin doğru işlendiğinden emin olun. Aksi halde, yanlış snapshot “indexlenebilir” hale gelebilir ya da başka bir state’e ait HTML farklı URL’ye karışabilir.

Güvenli Düzeltmeler: atomik publish, versiyonlu URL/etag, roll-forward/backward uyumu

Oda güncellemesini “yarım” yayınlamak cache karışmasını artırır. Atomik publish yaklaşımıyla; içerik revision’ı yükseltirken aynı anda render edilmesi gereken template/template variables tutarlı hale getirilmelidir.

Güvenli düzeltme tekniklerinden bazıları şunlardır:

• Versiyonlu render: Room_revision değiştikten sonra prerender ve CDN key’leri buna göre değişsin.
• ETag tabanlı doğrulama: Origin’de ETag/Last-Modified hesaplaması doğruysa CDN revalidation davranışı güçlenir.
• Roll-forward/backward uyumu: Cache key şemasını değiştirirken hem eski hem yeni key’leri belirli süre yönetebilecek geçiş stratejileri kurun.

Bu yaklaşım, yanlış sayfa önbelleğe düşse bile rollback senaryosunda eski içerik ile yeni içerik arasındaki eşleşmenin kontrol altında kalmasını sağlar.

Doğrulama: log/metric kontrolleri, test matrisi ve canary doğrulama adımları

Yanlış cache problemleri genellikle “gösterge” ile çözülür. Bu yüzden hem prerender hem CDN için log/metric metrikleri kurun: cache hit rate, miss rate, purge success rate, invalidation success rate, revalidation latency ve origin fallback sayıları.

Adım adım doğrulama (pratik bir test planı) önerisi:

1. Canary oda seçin: Sık güncellenen bir oda değil; kontrollü bir oda ile slug sabit kalacak şekilde içerik değiştirin.
2. Kontrollü event gönderin: Oda update event’i çalışsın; önce prerender invalidation, sonra CDN purge gerçekleşsin.
3. İstemci matrisiyle karşılaştırın: Normal tarayıcı, Googlebot simülasyonu ve mümkünse origin’e doğrudan erişim (bypass) ile HTML farkını ölçün.
4. Header ve cache key doğrulayın: İlgili response’larda Cache-Control/Surrogate-Control ve Vary değerlerini karşılaştırın.

Yaygın hatalar

Bu problemde en sık görülen hatalardan biri “invalidation yaptık, oldu” yanılgısıdır. Prerender tarafındaki invalidation başarılı görünse bile CDN purge yapılmadıysa ya da etiket mapping hatalıysa edge eski snapshot’u basmaya devam eder. Sonuç olarak kullanıcı ve bot aynı hatayı daha uzun süre görür.

Diğer yaygın hata, cache key’in URL’nin sadece bir kısmına (ör. slug) göre belirlenmesidir. Chat odalarında içerik değişkenleri (featured, moderasyon state, öne çıkan etiketler, dil/locale) URL dışında da değişebilir. URL sabit kalırken içerik değişirse, key tasarımı “değişmedi” diyerek yanlış snapshot döndürür. Bu nedenle Vary/header ve version/etag yaklaşımı birlikte ele alınmalıdır.

Kaçınılması gerekenler

Kaçınılması gerekenleri kısa tutuyorum; çünkü bu maddeler tekrar tekrar incident üretir. Özellikle chat sitelerinde dinamik durumlar (cookie/auth/etiket) olduğu için “tek bir genel cache kuralı” uygulamak risklidir.

• Her şeyi aynı cache key şemasına bağlamak: Private/public veya locale farklarını görmezden gelmek.
• Prerender ile CDN purge’ı bağımsız düşünmek: Etiketler ve sıralama eşlenmezse deterministik olmaz.
• Header tutarlılığını doğrulamamak: Prerender template ile SSR template aynı header davranışını üretmezse bot’ta farklı sonuçlar görürsünüz.
• Stale serving’i kontrol etmeden uzatmak: SEO kritik alanlar için yanlış içerik penceresi büyür.

Örnekler (senaryo odaklı)

Bu bölümde brief’te istenen dört örneği, doğrudan “ne olur → neden olur → nasıl çözülür” formatında özetliyorum. Amaç; ekiplerin aynı hatayı farklı sistemlerde tekrar etmesini engellemek.

Örnek 4: Parametreli URL’lerde (sort/filter/page) cache key eksik—çözüm: normalize etme + canonical eşleme.

Chat sitelerinde oda içeriği “sort/filter/page” parametreleriyle farklı görünüyorsa, CDN cache key yalnızca base URL’ye göre kurulursa yanlış liste HTML’i döner. Bu yüzden parametreleri normalize edin (sıralama, default değerler) ve canonical eşleme kuralı koyun. Örn. filter/page SEO için indexlenmeyecekse onları noindex/parametrelere indirgemek veya varyant key’e dahil etmek gerekir.

Yanlış sayfa önbelleğe düşerse geri alma (rollback) stratejisi

Cache karıştığında rollback çoğu zaman “hızlı purge + kontrollü publish” ile yapılır. Ancak yalnızca purge yapmak bazen yeterli değildir; çünkü yeni publish da cache key’i etkileyebilir. Bu yüzden rollback planı, event sırası ve cache key geçişini birlikte kapsamalıdır.

Pratik bir rollback yaklaşımı:

1. Hedeflenen cache objelerini purge et: Etiket/URL pattern bazlı purge ile yalnızca etkilenen oda varyantlarını temizleyin.
2. Origin’i tutarlı sürüme geri al: room_revision veya içerik versiyonunu önceki stabil sürüme roll back edin.
3. Prerender ve CDN arasında tekrar “deterministik sıra” yürütün: Önce prerender invalidation, sonra CDN purge uygulayın.

Cache-Control ve Surrogate-Control farkı bu problemde nasıl rol oynar?

Cache-Control standart cache davranışlarını yönlendirebilir; Surrogate-Control ise özellikle CDN/edge için karar verir. Eğer prerender yanıtında Surrogate-Control “cachele” derken SSR yanıtında “do not cache” gibi davranıyorsa, aynı URL farklı kaynaklardan farklı cachelenebilir. Bunun sonucunda bot ya da kullanıcıların farklı içerik görmesi mümkün olur.

Bu nedenle template doğrulaması yapın: prerender üretimiyle SSR üretiminin header çıktıları birebir uyumlu olmalı. En azından cache davranışı açısından eşdeğer değerler (TTL, s-maxage, stale-while-revalidate gibi) korunmalıdır.

Checklist ve Playbook (operasyonel kullanım)

Aşağıdaki kontrol listesi, bir oda güncelleme event’i sonrası “yanlış sayfa önbelleğe düşüyor mu?” sorusunu hızlıca cevaplamak için tasarlanmıştır. Incident’lerde çalışanlar için kısa bir playbook gibi düşünebilirsiniz.

• Cache key doğrulama: URL + locale + auth/public state + room_revision (veya etag/hash) key’e dahil mi?
• Header tutarlılığı: Prerender ve SSR response’larında Cache-Control/Surrogate-Control/Vary değerleri uyumlu mu?
• Event sırası: Origin publish → prerender invalidation → CDN purge sırası doğru mu?
• Etiket mapping: Prerender tag ile CDN purge tag aynı nesneyi mi hedefliyor?
• TTL/stale kontrolü: SEO kritik alanlar için stale serving süresi kabul edilebilir mi?
• Bot senaryosu: Googlebot simülasyonunda prerender çıktısı noindex gerektiren durumda doğru mu?
• Canary test: Güncellemeden sonra 1-3 dakika içinde HTML farkı beklediğiniz gibi mi?

Bir sonraki adım olarak log/metric dashboard’unuza “cache mismatch” sinyalleri ekleyebilirsiniz: Aynı oda için farklı sürüm ID görünüyor mu, purge sonrası cache hit devam ediyor mu, revalidation başarısız mı? Bu metrikler incident büyümeden yakalamanıza yardım eder.

Sık Sorulan Sorular (SSS)

Yanlış içerik CDN’de mi prerender’da mı? Ayırt etme yöntemleri neler? Normal kullanıcı ve Googlebot simülasyonunu birlikte test edin. Kullanıcı görüyorsa edge cache olasılığı artar; bot görüyorsa prerender snapshot olasılığı artar. Mümkünse origin bypass testi yaparak iki katmanı ayırın.

Prerender invalidation ile CDN purge aynı anda mı çalışmalı, hangi sırayla? Çoğu zaman deterministik sıra önerilir: origin publish → prerender invalidation → CDN purge. Mapping’ler ve header’lar tutarlı değilse “aynı anda” yaklaşımı kaçak sonuçlar doğurabilir.

Cache-Control ve Surrogate-Control farkı bu problemde nasıl rol oynar? Cache-Control tarayıcı/standart cache davranışını, Surrogate-Control ise edge/CDN davranışını etkiler. Prerender ve SSR’de farklıysa CDN yanlış nesneyi cache’leyebilir veya stale/revalidate davranışı değişebilir.

Oda güncellemesini her mesajda mı invalidation yapmalıyız, hangi eşik gerekir? Her mesajda purge yapmak maliyetli olur. Genellikle “SEO etkileyen alanlar” değişince (başlık/açıklama/özet/meta) invalidation/purge tetiklenir. Mesaj sayısı yoğun ama meta değişmiyorsa daha akıllı threshold veya “debounce” uygulayın.

Auth’li/etiketli oda içeriklerinde cache key’e cookie eklemek doğru mu? Cookie eklemek mümkün ama doğru yönetilmezse varyant patlaması yaratır. Bunun yerine auth durumunu ayıran “public/private render” ayrımı ve kontrollü Vary stratejisi daha güvenlidir.

Googlebot için prerender tetiklenme koşullarını nasıl güvenli ayarlarız? Bot-safe HTML üretin, noindex/noarchive gibi sinyalleri prerender çıktısında doğru verin ve cache header’larını tutarlılaştırın. Ayrıca prerender tetiklenen endpoint’lerde içerik state’ini doğru etiketleyin.

Yanlış sayfa önbelleğe düşerse geri alma (rollback) stratejisi nasıl yapılır? Hedefli purge + origin versiyon geri alımı + prerender invalidation/CND purge sırasını yeniden uygulama ile geri dönün. Versiyonlu key yaklaşımı rollback’te veri tutarlılığını korur.

Nasıl kontrol edilir? (adım adım doğrulama önerisi)

Bu başlık, pratik bir “nasıl kontrol edilir” mini prosedürüdür. Amaç; ekiplerin 30-60 dakikada kök nedeni bulabilmesini sağlamaktır.

1. Edge’de görüntülenen HTML’i yakalayın: Cache hit/miss göstergeleriyle birlikte aynı URL’den yanıt alın ve oda revision/etag değerini kontrol edin.
2. Prerender snapshot’ını karşılaştırın: Googlebot simülasyonu ile gelen HTML’de revision uyuşuyor mu? Header’lar tutarlı mı?
3. Purge sonrası tekrar deneyin: Invalidation→purge sırası doğru yapıldıysa kısa süre içinde yeni revision görünmeli. Görmüyorsanız purge hedefi (key/tag) yanlış olabilir.
4. Varyans ve parametre normalize kontrolü: Aynı oda için sort/filter/page varyantlarında canonical uyumu ve cache key normalize edildi mi?

Bu kontrol akışı, brief’in vaadini somutlaştırır: oda içerikleri güncellenirken CDN cache ile prerender cache arasındaki çakışmayı yönetmek için hem mimari (cache key/varyant) hem operasyonel (purge sırası, mapping, TTL) kararlar gerekir.

İçerik yayılımı ve SEO yönetimine küçük not

Chat sitelerinde oda içeriği sadece kullanıcı arayüzü için değil, arama sonuçlarındaki snippet ve index davranışı için de önemlidir. Bu yüzden yanlış HTML’in cache’den çıkması yalnızca UX’ı etkilemez; SEO performansını da doğrudan etkiler. Doğru invalidation/purge ve doğru canonical eşleme, crawler davranışını daha öngörülebilir hale getirir.

Bu konuyle ilişkili olarak oda kapanınca index yönetimi gibi alanlarda da doğru model kullanmak gerekir; bu tip kararların cache davranışıyla çatışmaması için aynı mantığı event temelli sürümleme ile birleştirin.

Benzer bazı yaklaşım ve stratejiler için şu iç yazılara da göz atabilirsiniz: Oda Kapanınca Kapanış Arayüzü SEO’su: 404/410 Yerine Eşik Geçiş Modeli ile Indexi Doğru Yönetme ve Chat’te Dil/Tema Tercihi URL’de Varyant Oluşturuyorsa Canonical ve Hreflang Kurgusu: Tercih Parametresini SEO’dan Ayrıştırma.