Sezonluk Trafik Patlamalarına Hazırlık: Hosting Ölçekleme, Önbellek ve Okunur Mod Stratejileri

Sezonluk Trafik Patlamalarını Ciddiye Almayanların Sonra Yaşadığı Pişmanlık

Black Friday, 11.11, bayram kampanyaları, yılbaşı indirimleri… Pazarlama tarafında harika fırsatlar, sistem tarafında ise yanlış planlanırsa kabusa dönüşebilecek dönemler. Trafik patlaması dediğimiz şey, normalde dakikada 20-30 oturum alan sitenin, birkaç saat içinde dakikada 300-500 oturuma çıkmasıdır. Bu artış; CPU, RAM, disk I/O, veritabanı bağlantı sayısı, hatta ağ bant genişliği üzerinde bir anda basınç oluşturur.

Pratikte gördüğümüz tablo genelde şöyle oluyor: Kampanya için bütçe harcanıyor, reklamlar açılıyor, kullanıcılar siteye akmaya başlıyor ve en kritik anda “site çok yavaş” şikâyetleri geliyor. Bir adım sonrası ise 502/504 hataları, beyaz ekranlar ve yarım kalan ödemeler. En acı tarafı, bu hasarın çoğu aslında birkaç hafta önceden yapılacak doğru kapasite planlama, önbellek stratejileri ve iyi kurgulanmış bir “okunur mod” (read-only mode) senaryosu ile rahatlıkla önlenebilir.

Bu yazıda DCHost olarak kendi sahada gördüğümüz vakalardan süzülen deneyimle; sezonluk trafik patlamalarına hosting tarafında nasıl hazırlanmanız gerektiğini adım adım ele alacağız. Ölçekleme senaryoları, tam sayfa ve mikro önbellek, CDN ve tarayıcı cache ayarları, okunur mod kurguları ve operasyonel hazırlık checklist’i… Amaç, kampanyanın teknik tarafta “olaysız” geçmesi.

Sezonluk Trafik Patlaması Nedir, Nereden Gelir ve Neden Tehlikelidir?

Çoğu zaman trafik patlaması tek kaynaktan gelmez. Aynı anda şu kanallar birikimli etki oluşturur:

• Yoğun performanslı reklam kampanyaları (Google Ads, sosyal medya reklamları)
• E-posta bülteni ve SMS ile duyurulan özel indirimler
• Influencer veya iş birliği kampanyaları
• Organik tarafta güçlü kampanya sayfalarına gelen SEO trafiği

Bu dönemde sadece sayfa görüntüleme sayısı artmaz; aynı anda:

• Daha fazla kullanıcı sepet doldurur, ödeme başlatır
• Filtreli arama, kategori gezintileri, kampanya koşulu hesaplamaları artar
• Veritabanına yazan aksiyonlar (sipariş, kupon kullanımı, puan, üyelik) yoğunlaşır

Yani trafik patlaması yalnızca “daha çok istek” değildir, daha ağır istekler anlamına da gelir. Normalde 1 CPU çekirdeği ile rahatça çalışan bir WooCommerce mağazası, kampanya sırasında:

• PHP-FPM havuzunda maksimum çocuk sürecine takılabilir
• MySQL’de bağlantı sayısı tavan yapabilir
• Disk IOPS sınırına yaklaşarak sorguların cevap süresini uzatabilir

Bu tabloyu gerçekçi ölçmek için kapasite analizi ve yük testi konusu kritik. DCHost blogumuzda yayınladığımız trafik patlamasından önce load test yapma rehberi bu aşamada elinizin altında olmalı. Planlama yapmadan önce mevcut mimarinin nerede koptuğunu bilmek, doğru ölçeklemeyi seçmenin tek sağlıklı yolu.

Kapasite Planlama: Kaç Kullanıcıyı Güvenle Taşıyabileceğinizi Sayılara Dökmek

“Şu kadar vCPU, bu kadar RAM yeter mi?” sorusu tek başına hiçbir şey ifade etmez. İhtiyacı belirlemek için kampanya öncesi şu dört adımı mutlaka öneriyoruz:

1. Baz (normal gün) metriklerini netleştirin

Önce bugünü bilmek gerekiyor. Normal bir günde:

• Ortalama eş zamanlı kullanıcı sayınız (Google Analytics, Matomo vb.)
• Ortalama istek/saniye ve zirve saatlerdeki istek/saniye (sunucu loglarından veya izleme araçlarından)
• CPU, RAM, disk I/O ve veritabanı bağlantı kullanım oranlarınız

Bu veriler elinizde yoksa, DCHost üzerindeki VPS ya da dedicated sunucunuzda basit monitoring (Netdata, Prometheus + Grafana, panel istatistikleri) kurarak en azından 1-2 haftalık baz veri toplayın.

2. Kampanya hedeflerinize göre trafik çarpanını belirleyin

Pazarlama ekibinizle masaya oturup şu soruları netleştirin:

• Kampanya döneminde normal güne göre kaç kat oturum hedefleniyor? (x3, x5, x10?)
• Bu artış günün tamamına mı yayılacak, yoksa belli saatlerde mi yoğunlaşacak?
• Kampanyanın en yoğun saatinde beklenen eş zamanlı kullanıcı tahmini nedir?

Örneğin normalde zirvede 100 eş zamanlı kullanıcı görüyorsanız ve Black Friday için x5 hedefliyorsanız, 500 eş zamanlı kullanıcıyı taşıyabilecek bir mimari planlamalısınız.

3. Yük testi ile teoriyi sahada doğrulayın

Sayıları tahmin etmek güzeldir ama yetmez; mutlaka sahada doğrulamak gerekir. Bunun için staging ortamınızda, olabildiğince canlıya benzeyen bir kopya üzerinde, k6 / JMeter / Locust gibi araçlarla senaryo bazlı yük testleri yapabilirsiniz. Adım adım nasıl ilerleyeceğinizi, yük test rehberimizde detaylı anlattık.

Buradaki amaç şudur:

• Hangi eş zamanlı kullanıcı sayısında CPU %90+ kullanımına çıkıyor?
• Hangi noktada yanıt süreleri keskin şekilde bozuluyor? (örneğin 500 ms → 2-3 saniye)
• Darboğaz PHP mi, veritabanı mı, disk mi, yoksa ağ mı?

4. Güvenlik payı bırakın

Testlerde 400 eş zamanlı kullanıcıya kadar sisteminiz dayanıyorsa, kampanya hedefiniz 300 ise, burada yine de %20-30 güvenlik payı bırakmak mantıklıdır. Çünkü gerçek dünyada:

• Cache oranı her zaman laboratuvar ortamı kadar yüksek olmayabilir
• Ziyaretçi davranışları tahmin ettiğinizden farklı olabilir
• Arka planda cron, yedek, raporlama işleri sisteme yük bindirebilir

Kapasite planlamasını netleştirdikten sonra sıra, bu yükü taşıyacak hosting mimarisini seçmeye ve önbellek stratejisini oturtmaya geliyor.

Hosting Tarafında Ölçekleme Senaryoları: Paylaşımlı’dan Çok Sunuculu Mimarilere

DCHost’ta farklı ölçeklerde projeler gördükçe fark ettiğimiz en önemli şey şu: Trafik patlaması dönemine gelirken “bir üst pakete geçmek” her zaman tek başına çözüm değil. Önemli olan, doğru mimariyi seçmek.

Senaryo 1: Orta ölçekli e-ticaret – Paylaşımlıdan yönetilen VPS’e geçiş

Yeni başlayan birçok WooCommerce veya küçük framework tabanlı mağaza, ilk yılını paylaşımlı hosting ile rahat geçiriyor. Ancak Black Friday gibi dönemlerde:

• cPanel CPU/IO limitleri sık sık doluyor
• “Resource Limit Reached” hataları görülüyor
• Yoğun saatlerde TTFB ciddi artıyor

Böyle bir yapı için en sağlıklı adım genellikle yönetilen bir VPS’e geçip, CPU/RAM kaynaklarını daha esnek kullanmak ve PHP-FPM + veritabanı ayarlarını projeye özel optimize etmek oluyor. Bu konuyu daha genel bir çerçevede paylaşımlı hosting’den VPS’e geçiş rehberimizde detaylandırmıştık.

Sezonluk trafik patlaması öncesi böyle bir geçiş planlıyorsanız:

• Önce staging ortamında taşıma ve testleri bitirin
• DNS TTL değerlerini kampanyadan birkaç gün önce düşürün
• Geçişi kampanyadan minimum 1 hafta önce tamamlayıp sistemin “oturmasına” izin verin

Senaryo 2: Büyüyen mağaza – Ayrı veritabanı ve önbellek sunucusu

Satış hacmi, ürün sayısı ve eş zamanlı kullanıcı sayısı büyüdükçe, tek VPS üzerinde hem web sunucusu hem veritabanı hem de Redis/Memcached çalıştırmak bir noktadan sonra anlamlı olmuyor. Özellikle WooCommerce ve benzeri yapılarda:

• Uygulama sunucusu (PHP-FPM, Nginx/Apache/LiteSpeed)
• Veritabanı sunucusu (MySQL/MariaDB/PostgreSQL)
• Önbellek sunucusu (Redis, bazen Memcached)

rollerini ayırmak, hem ölçekleme hem de sorun giderme açısından büyük fayda sağlıyor. DCHost blogunda yayınladığımız WooCommerce için ayrı veritabanı ve önbellek sunucusu ne zaman mantıklı yazısında bu eşiği ne zaman geçtiğinizi netleştiren teknik göstergeleri paylaştık.

Sezonluk patlama dönemine hazırlanırken, en azından:

• Veritabanını ayrı bir VPS’e taşıma
• Redis’i yine ayrı, küçük ama hızlı bir örneğe alma

gibi adımlar atmak, ani yük artışında “tek nokta” üzerindeki baskıyı ciddi oranda azaltır.

Senaryo 3: Yüksek hacimli kampanyalar – Yatay ölçekleme ve load balancer

Reklam bütçeleri ciddi seviyelere çıktığında, tek sunucuyu büyüterek (dikey ölçekleme) ilerlemek bir noktadan sonra riskli hale gelir. Bu durumda:

• Ön tarafta bir load balancer (Nginx/HAProxy vb.)
• Arkasında 2+ web uygulama sunucusu
• Ortak veritabanı kümesi ve paylaşılan dosya alanı (NFS, object storage, rsync tabanlı senkron vb.)

ile çok sunuculu mimariye geçmek daha sağlıklıdır. Küçük projeler için basit yük dengeleme kurgusunu, Nginx reverse proxy ve basit load balancer kurulumu rehberimizde anlattık.

DCHost tarafında VPS, dedicated sunucu veya colocation kullanan müşterilerimizle bu tip senaryolarda genellikle şu yolu izliyoruz:

1. Önce tek sunucu üzerinde önbellek stratejisini maksimuma çıkarma
2. Ardından web katmanını ikiye bölme (aynı imajdan çoğaltma)
3. Son olarak dengesiz noktayı veritabanı tarafında replikasyon veya okuma/yazma ayrımı ile çözme

Önbellekleme Stratejileri: Trafik Patlamasının Yüzde 80’ini Cache’e Vurdurmak

Ne kadar güçlü sunucu kullanırsanız kullanın, sezonluk trafik patlamalarında gerçekten nefes aldıran şey iyi kurgulanmış bir önbellek katmanıdır. Önbelleği üç seviyede düşünmek gerekiyor:

• Uygulama ve nesne önbelleği (Redis / Memcached)
• Tam sayfa (full-page) ve mikro önbellek
• CDN ve tarayıcı önbelleği

Uygulama ve nesne önbelleği

WordPress/WooCommerce, Laravel gibi popüler uygulamalar zaten nesne önbelleği için hazır eklenti ve paketlere sahip. DCHost blogda yayınladığımız PHP session ve cache depolamasını doğru seçme rehberi ile Redis/Memcached kullanımının performansa etkilerini detaylandırdık.

Sezonluk patlamalar öncesi şu adımları mutlaka gözden geçirin:

• WordPress/WooCommerce için Redis veya Memcached object cache aktif mi?
• Laravel’de cache driver’ınız dosya yerine Redis’e taşındı mı?
• Session’lar yoğun trafikte I/O problemi çıkaracak şekilde diskte mi, yoksa RAM tabanlı bir depoda mı tutuluyor?

Tam sayfa ve mikro önbellek (full-page cache + microcache)

Özellikle ürün ve kategori sayfalarında HTML’nin tamamını cache’lemek, trafik patlaması esnasında hayat kurtarıyor. WordPress dünyasında bu işi yapan birçok eklenti var; biz DCHost olarak sıklıkla Nginx FastCGI cache, LiteSpeed Cache veya Varnish gibi çözümleri de öneriyoruz. Detaylı ayar seviyesinde merak ediyorsanız, WordPress’te tam sayfa önbellekleme rehberimizi inceleyebilirsiniz.

Burada kilit nokta, kampanya döneminde:

• Ürün ve kategori sayfaları için yüksek cache süresi (örneğin 5-15 dakika)
• Sepet, ödeme, kullanıcı hesabı gibi sayfalar için cache bypass
• Stok ve fiyat değişimi gibi durumlarda seçici cache purging mekanizması

Kuruluğu sağlamaktır. Eğer önbelleği hiç kullanmıyorsanız, yük testi sonuçlarınız, cache devreye alındıktan sonra dramatik şekilde iyileşebilir.

Daha ileri senaryolarda Nginx ile mikro önbellekleme (1-5 saniyelik cache) de çok etkilidir. Özellikle yoğun okuma yükü olan, ama milisaniyeler içinde çok değişmeyen dinamik endpoint’lerde (örneğin anlık stok sayfası, yoğun arama sonuçları) mikrocache, veritabanı üzerindeki yükü ciddi seviyede düşürebilir. Teknik detayları merak edenler için Nginx mikro önbellekleme rehberimiz iyi bir başlangıç noktası.

CDN ve tarayıcı önbelleği

HTML tarafını cache’ledikten sonra sıradaki büyük kazanç alanı, statik dosyalar: CSS, JS, görseller, fontlar. Bunları bir CDN üzerinden, uzun tarayıcı cache süreleriyle sunmak, hem TTFB’yi iyileştirir hem de origin sunucu üzerindeki yükü önemli ölçüde azaltır.

Şu ayarları kampanyadan önce mutlaka elden geçirin:

• Cache-Control ve Expires başlıkları (özellikle immutable ve uzun max-age kullanımı)
• CDN üzerindeki cache anahtarı (cache key) ve varyasyon kuralları
• Görseller için WebP/AVIF dönüşüm kurguları

Bu konuda teoriden pratiğe geçişi, CDN ve tarayıcı önbelleğinde cache busting stratejileri ile tarayıcı ve CDN önbellekleme neden bu kadar kritik yazılarımızda detaylı anlattık. Kampanya öncesi yapılacak küçük bir yanlış (örneğin her deploy’da tüm static URL’lerini değiştirmek) CDN faturasında gereksiz patlama ve origin sunucuda ekstra yük anlamına gelebilir.

stale-while-revalidate ve stale-if-error ile kesinti riskini yumuşatmak

HTTP cache mekanizmalarında son dönemin en hayat kurtaran özelliklerinden ikisi stale-while-revalidate ve stale-if-error. Özetle:

• stale-while-revalidate: Cache süresi dolduğunda, eski (stale) içeriği kullanıcıya hemen gösterirken, arka planda yeni içeriği sessizce yeniler.
• stale-if-error: Origin hata verirse (örneğin 500, 502), cache’teki eski içeriği bir süre daha sunmaya devam eder.

Bu iki başlık, özellikle Black Friday gibi yoğun kampanyalarda saniyelik CPU pik’lerinde ya da kısa süreli veritabanı sorunlarında sitenin tamamen göçmesini engelleyebilir. Ayrıntılı anlatım ve örnek header’lar için stale-while-revalidate ve stale-if-error nasıl hayat kurtarır yazımıza mutlaka göz atın.

Okunur Mod (Read-Only Mode): En Kötü Senaryoyu Bile Yönetilebilir Kılmak

Tüm hazırlıklara rağmen, beklediğinizin çok üzerinde bir trafikle karşılaşabilirsiniz. Böyle anlarda seçenekleriniz:

• Siteyi tamamen kapatıp bakım sayfası göstermek
• Veya en azından “okunur mod” ile kritik olmayan yazma işlemlerini devre dışı bırakmak

İkincisi, kullanıcı deneyimi ve SEO açısından çok daha zarif bir çözüm. DCHost blogda bakım modu ve planlı kesinti yönetimi yazımızda tam kesinti senaryolarını işlemiştik; burada ise odak, sitenin büyük oranda ayakta kalmasını sağlayan okunur mod stratejisi.

Okunur modda neyi kapatıp neyi açık bırakmalısınız?

Okunur modun mantığı basit: Veritabanına yazan işlemleri (write) mümkün olduğunca azaltıp, okumaları (read) devam ettirmek. Tipik bir e-ticaret sitesi için şu yaklaşım mantıklıdır:

• Açık kalacaklar: Ürün listeleme ve detay sayfaları, kategori ve filtreler, blog içerikleri, sık sorulan sorular, statik sayfalar.
• Geçici olarak kapatılacaklar: Yeni üyelik oluşturma, profil güncelleme, yorum yazma, canlı sohbet (çok yoğun DB kullanıyorsa).
• Duruma göre kapatılacaklar: Sepet ve ödeme adımları (kritik veri bütünlüğü riske giriyorsa).

Uygulama mimarisine göre, okunur modu aşağıdaki yöntemlerle kurgulayabilirsiniz:

• Veritabanının yazma haklarını geçici olarak kısıtlamak (örneğin yalnızca belirli tabloları read-only yapmak)
• Uygulama seviyesinde, belirli endpoint’lere POST/PUT isteklerini 503 veya kullanıcı dostu bir mesajla karşılıklandırmak
• WordPress/WooCommerce için özel bir “kampanya modu” eklentisiyle yazma işlemlerini uçtan uca devre dışı bırakmak

Okunur modun operasyonel senaryosu

Okunur modun işe yaraması için, sadece teknik olarak mümkün olması yetmez; net bir runbook’a da ihtiyacınız var. Örneğin:

1. Monitoring tarafında CPU veya istek/saniye belli bir eşiği aştığında alarm tetiklenir.
2. Nöbetçi teknik ekip, önceden yazılmış bir script veya Ansible playbook’u ile siteyi okunur moda alır.
3. Destek ekibiniz, müşteri hizmetleri ve sosyal medya ekibine bilgilendirme notu gönderir (kullanıcıya ne söyleyeceklerini bilsinler).
4. Yük düşmeye başladığında benzer şekilde, kontrollü bir şekilde yazma işlemleri yeniden açılır.

Böyle bir senaryo, özellikle yoğun medya ilgisi alan anlık kampanyalarda (TV reklamı sonrası trafik gibi) siteyi kurtaran son savunma hattı olabilir.

Operasyonel Hazırlık: İzleme, Alarm, Rollback ve DCHost ile Çalışma

Ölçekleme ve önbellek işin teknik yarısıysa, operasyonel hazırlık da diğer yarısıdır. Trafik patlaması döneminde rahat etmek istiyorsanız, kampanya başlamadan önce şu başlıkları checklist’e ekleyin:

İzleme ve alarm sistemi

En azından şu metrikler için alarm eşikleri belirleyin:

• CPU kullanım oranı (örneğin 5 dakika boyunca %85 üzeri)
• RAM kullanımı ve swap kullanımı
• Disk I/O bekleme süresi
• MySQL bağlantı sayısı ve yavaş sorgu sayısı
• HTTP 5xx hata oranı ve ortalama yanıt süresi

Bu verileri manuel olarak panelden takip etmek yerine, otomatik alarm kurmak şart. DCHost altyapısında, kullandığınız hizmet tipine göre farklı izleme çözümlerini entegre ederek (Netdata, Prometheus, harici uptime servisleri) bu görünürlüğü sağlayabilirsiniz.

Rollback ve deploy stratejisi

Kampanya öncesi son anda kod deploy etmek, genelde en riskli hamledir. Yine de yapmak zorundaysanız:

• Blue-green veya canary dağıtım gibi sıfır kesinti stratejileri kullanın
• Her zaman net bir rollback planınız (ve test edilmiş script’leriniz) olsun
• Deploy sonrası kısa süreli yük testleri yaparak yeni sürümün davranışını ölçün

Bu konuda adım adım rehber isterseniz, blue-green deployment ile sıfır kesintiyle güncelleme yazımız tam da bu ihtiyaca göre hazırlandı.

Veritabanı ve sorgu optimizasyonu

Sezonluk patlamalarda veritabanı tarafı genellikle ilk çöken katman olur. Özellikle:

• Büyük ürün kataloğu ve karmaşık filtreler
• Kampanya koşullu fiyat/kupon hesaplamaları
• Yoğun sipariş yazma işlemleri

MySQL/MariaDB üzerinde ciddi baskı yaratır. Kampanya öncesi mutlaka:

• Index’leri gözden geçirin
• Slow query log’u açıp en sık ve en yavaş sorguları analiz edin
• Gerekirse kritik sorguları yeniden yazın veya cache’e alın

Bu konuda e-ticaret odaklı pratik ipuçları için WooCommerce ve büyük katalog siteleri için MySQL indeksleme ve sorgu optimizasyonu rehberimize göz atabilirsiniz.

DCHost ekibi ile koordinasyon

Eğer DCHost üzerinde VPS, dedicated veya colocation hizmeti kullanıyorsanız, sezonluk kampanyalarınız bizim için de kritik. Trafik patlaması döneminden önce:

• Kampanya tarih ve saatlerini bizimle paylaşın
• Beklediğiniz trafik artışı ve hedef metrikleri (eş zamanlı kullanıcı, tahmini istek/saniye) iletin
• Özel önlem gerektiren backend işlemleriniz (cron’lar, raporlar, yedekler) varsa, kampanya saatlerine denk gelmeyecek şekilde zamanlamasını birlikte gözden geçirelim

Böylece hem altyapı tarafında proaktif önlem alabilir, hem de anlık bir sorun olduğunda müdahale süremizi minimuma indirebiliriz.

Özet ve Yol Haritası: Kampanyaya Son Hafta Kalmadan Bu Listeyi Bitirin

Sezonluk trafik patlamaları, doğru planlandığında markanız için büyük bir büyüme fırsatı. Doğru planlanmadığında ise hem maddi kayıp hem de itibar zedelenmesi anlamına geliyor. DCHost olarak sahada gördüğümüz en büyük fark, “rastgele güçlü sunucu” ile planlı mimari + iyi önbellek + okunur mod senaryosu arasındaki uçurum.

Kendinize şu soruları sorarak başlayabilirsiniz:

• Normal günlerdeki kapasitemi sayılarla biliyor muyum?
• Kampanya hedefime göre kaç kat trafik bekliyorum ve bunu yük testiyle doğruladım mı?
• Object cache, tam sayfa cache, mikrocache ve CDN/tarayıcı cache katmanlarım doğru kurgulandı mı?
• Aşırı yük anında devreye alabileceğim net bir okunur mod senaryom var mı?
• İzleme, alarm, rollback ve DCHost ekibi ile iletişim planım hazır mı?

Eğer bu sorulardan birkaçına bile “emin değilim” diyorsanız, kampanya tarihleri yaklaşmadan aksiyon alma zamanıdır. Dilerseniz mevcut altyapınızı birlikte gözden geçirip, DCHost üzerinde sizin proje profilinize uygun bir ölçekleme, önbellek ve okunur mod stratejisi kurgulayabiliriz. Böylece Black Friday ve benzeri sezonluk trafik patlamalarında, teknik tarafı düşünmek zorunda kalmadan sadece satış ve kampanya performansına odaklanabilirsiniz.