İndirim Günü Sunucu Çökmesini Önle: Net Plan ve Kontrol Listesi

E-ticaret indirim günleri (kampanya, flash sale, sezon sonu) tipik olarak aynı anda üç problemi büyütür: ani trafik artışı, veritabanı yükü ve tarayıcı/robot kaynaklı istek yoğunluğu. Bu üçü birlikte olduğunda “sayfa yüklenmiyor” durumuna kadar giden zincirleme performans düşüşleri görülebilir. Bu rehberde hedef, çökme yaşamadan önce riskli noktaları somut ölçümlerle yakalamak ve kampanya sırasında uygulanacak adımları netleştirmektir. Ayrıca VDS/VPS veya yönetilen hosting fark etmeksizin uygulanabilir bir plan ve kontrol listesi paylaşıyorum.

1) Çökme sebebini doğru teşhis edin: Yük nerede birikiyor?

İndirim günü çökmesinin en sık kökenleri; web katmanı (web server), uygulama katmanı (PHP/Node/Rails vb.) ve veri katmanı (özellikle MySQL/PostgreSQL) şeklinde üç başlıkta toplanır. Bu nedenle kampanya öncesi “hedef ölçüm seti” oluşturun.

Hızlı teşhis için 3 metrik (kampanya başlamadan)

TTFB (Time to First Byte): Uygulamanın cevap süresi. Özellikle önbellek (cache) yoksa aniden yükselir.
CPU load ve Load average: Uygulama server’ında iş yoğunluğu. Tek çekirdek tıkanması bile belirtidir.
Veritabanı bağlantı sayısı ve sorgu süresi: MySQL’de “Too many connections” veya yavaş sorgular (slow query) zincir etkisi yaratır.

Hız göstergesi: Başarıyı “sayfa açıldı” yerine ölçün

Tek bir sayfanın yüklenip yüklenmediğine bakmak yerine aşağıdaki gibi davranın: - Sepet/ödeme ekranına giden istekler için TTFB trendi - “Ürün listeleme” (category) sayfalarında cache hit oranı - Veritabanında en çok çalışan sorguların süre dağılımı

Bu ölçümler kampanya öncesi “normal” değerleri belirlemenizi sağlar. Kampanya günü, bu değerlerden sapma görüldüğünde müdahale planı devreye girer.

2) Kapasiteyi indirim gününe göre ayarlayın: ölçekleme + limitler

İndirim günü çökmesinin en net önlemi, tek noktada her şeyi istemek yerine kapasiteyi “tepe değer” için planlamaktır. Burada iki yaklaşım var: ölçekleme (scale) ve sınırlama (rate limiting/queue).

Ölçekleme: VDS/VPS’te pratik yöntemler

Web katmanı için: mümkünse birden fazla uygulama worker’ı veya process sayısı artırılır.
CDN ile ayrıştırma: statik içerik ve cache edilebilir sayfalar origin yerine CDN’den gelir.
Load balancer (varsa): uygulama server’larına dağıtım yapılır.

Sınırlama: bot ve aşırı istekleri kontrol altına alın

IP bazlı rate limiting: özellikle arama, ürün listeleme ve “hızlı bak” endpoint’lerinde.
Bot tarama azaltma: WAF (Web Application Firewall) kuralları ve “challenge” mekanizmaları.
Ödeme katmanında: ödeme denemelerini (checkout retries) kontrol eden mantık. Aynı kullanıcı/cihazın ardışık başarısız denemeleri daha sıkı sınır alır.

Ayrıca kampanya gününde “bağlantı sonlanması” (connection saturation) yaşanmaması için uygulama seviyesinde bağlantı havuzu (pooling) mantığı çalıştırın. Veritabanına kontrolsüz bağlantı açmak, çöküşün doğrudan tetikleyicilerindendir.

3) Cache stratejisi: çöküşü genellikle tek adım durdurur

İndirim günlerinde en hızlı kazanım çoğu zaman cache’tir. Ancak “her şeyi cache’leyelim” yaklaşımı yanlış sonuç verir. Net hedef, dinamik olmayan ve pahalı hesaplanan alanları ayırmaktır.

Cache’i doğru katmanlarda düşünün

CDN cache: görsel, CSS/JS gibi statik kaynaklar ve cache’lenebilir HTML parçaları.
Uygulama cache: ürün listesi, kategori sayfası, sayfa bileşenleri.
Tarayıcı cache: kaynakların tekrar indirilmesini azaltır.

Hangi sayfalar daha çok fayda sağlar?

Aşağıdaki tablo, tipik e-ticaret akışında hangi bileşenlerin cache ile en çok rahatladığını gösterir.

Senaryo	Cache’e uygunluk	Neden	Not (kampanya günü)
Ürün listeleme (kategori)	Yüksek	Sürekli aynı içerik döner, DB yükü düşer	Stok bilgisini doğru zamanda güncelle
Ürün detay sayfası	Orta-Yüksek	Görsel ve açıklama sabittir	Fiyat/indirimi dinamik ise parçalı cache kullan
Arama sonuçları	Orta	Kullanıcıya göre değişir	Rate limiting ile destekle
Sepet/checkout	Düşük	Kullanıcıya özel	Origin yükünü artırmamak için tasarım kritik
Marka sayfaları	Yüksek	Genelde statik	CDN varyasyonlarını doğru ayarla

Cache prewarming: kampanya başlamadan ısıtın

Cache prewarming, kampanya öncesi “en çok ziyaret edilecek” URL’leri önceden çağırıp cache’leri doldurma işlemidir. Bu sayede kampanya anında birden fazla kullanıcı cache miss yaşayıp origin’i boğmaz. - En azından ilk 100–300 URL (top kategori, en popüler ürünler) - Hedef: kampanya başlama anında TTFB dalgalanmasını azaltmak

4) Veritabanı ve uygulama: “Bağlantı + sorgu” çöküşün merkezidir

İndirim gününde veritabanı genelde iki sebeple zorlanır: hızlı artan sorgu hacmi ve aynı anda yapılan aynı sorgular (özellikle stok/fiyat ve kişiselleştirme).

MySQL/PostgreSQL için net kontrol adımları

Slow query log: Kampanya öncesi “en yavaş 10 sorgu”yu tespit edin.
İndeks kontrolü: WHERE ve JOIN kullanılan alanlarda indeks yoksa yük katlanır.
Bağlantı limitleri: MySQL’de max_connections aşılırsa uygulama yeni istekleri işleyemez.

Not: “snapshot yedekleme” veritabanı performansı için çözüm değildir; ama çöküş sonrası rollback planını destekler. Performans sorunu için asıl kaynak sorgu/indeks/limitlerdir.

Uygulama tarafında yapılacak net iyileştirmeler

Worker sayısı ve queue ayarı: Örneğin gönderim/posta işleri veya arka plan işleri kampanya sırasında kuyrukta beklemelidir.
Gerekli olmayan senkron işlemleri ayırın: Sipariş sonrası fatura e-postası gibi işlemleri asenkron hale getirin.
Stok ve fiyat okuma mantığı: Aynı anda çok istek aynı tabloları kilitliyorsa transaksiyon tasarımı gözden geçirilmeli.

5) CDN + WAF + DDoS koruması: trafik artışını origin’den ayırın

İndirim günlerinde trafik sadece “insan” değildir. Botlar, scraper’lar ve anormal istekler origin’i tüketir. Bu yüzden CDN ve WAF/anti-DDoS üçlüsü birlikte ele alınmalıdır.

Basit ama etkili kurgu

CDN: Statik kaynaklar ve cache’lenebilir içerik origin’e uğramaz.
WAF: SQLi/XSS gibi saldırılar kadar, anormal istek paternlerini de engeller.
DDoS: Yüksek paket/alan yoğunluğunu filtreler.

Uygulama katmanını koruyan ayarlar

URL bazlı kurallar: Ödeme dışı endpoint’lerde daha agresif rate limit.
Challenge sayfası: Bot şüphesinde otomatik CAPTCHA/JS challenge (hangi mekanizma kullanılıyorsa) ile istek azaltma.
Cache varyasyonları: “Dil/ülke/cihaz” gibi varyasyonlar cache’i parçalayabilir; varyasyonları minimumda tutun.

6) İzleme, alarm ve rollback: kampanya sırasında “ne zaman ne yapacağız?”

Hazırlıkların işe yaradığı yer kampanya anıdır. O yüzden “izleme paneli + alarm eşiği + rollback aksiyonu” belirleyin.

Kampanya için önerilen alarm seti (net eşiğe bağlayın)

Aşağıdaki alarm başlıklarını kendi sistem ölçümünüze göre eşiklerle kurgulayın: - TTFB %50–%100 artış (kampanya başlamadan önceki 15 dakikaya göre) - 5xx hata oranı (ör. %1–%2 üzeri) - CPU load %80 üzeri (10 dakikadan uzun sürerse) - Veritabanı bağlantı sayısı limit kullanımı (ör. %70+)

Rollback planı: tek tuş değil, net prosedür

Kampanya sırasında yeni bir sürüm yayınlandıysa rollback prosedürü önceden yazılmalıdır: - Yeni sürüm varsayılan olarak kapalı feature flag ile açılıyorsa avantaj sağlar. - Cache değişiklikleri (ör. TTL artırma) beklenenden fazla istikrarsızlık yaratırsa geri alma planı olmalı.

Olası senaryolar ve hızlı müdahale

Ödeme sayfası yavaşladı: Sepet/checkout için DB sorgu sayısını kontrol edin, ödeme gateway retry’lerini sınırlandırın.
Ürün listeleme yavaşladı: Cache hit oranı düşmüş olabilir; prewarming eksik veya cache TTL kısa olabilir.
Hata artışı başladı: Worker/queue tıkanması veya veritabanı bağlantı limiti aşımı olabilir; önce 5xx artışının hangi endpoint’te başladığını bulun.

Karşılaştırmalı kontrol listesi: Kampanya öncesi yap (ve işaretle)

Aşağıdaki listeyi kampanya başlamadan önce tek tek kontrol edin. Amaç “her şeyi yapmak” değil, çökme riskini doğuran kritik başlıklarda boşluk bırakmamaktır.

[ ] TTFB normal değeri (kampanya öncesi) çıkarıldı
[ ] Slow query: en yavaş sorgular listelendi ve giderildi
[ ] Veritabanı bağlantı limiti uygulama tarafında kontrol ediliyor
[ ] CDN aktif ve statikler origin’e yük bindirmiyor
[ ] Cache stratejisi net: kategori ve listeleme cache’leniyor
[ ] Cache prewarming yapıldı (ilk popüler URL’ler)
[ ] WAF + bot önleme kuralları kampanya modunda optimize edildi
[ ] Rate limiting özellikle arama/listleme endpoint’lerinde devrede
[ ] Checkout için asenkron işlemler ayrıştırıldı
[ ] İzleme paneli ve alarm eşiği hazır
[ ] Rollback prosedürü yazılı ve test edildi

Sonuç: İndirim günü çökmesini “son dakika” değil, ölçümle önleyin

İndirim günlerinde sunucu çökmesini durduran yaklaşım, tek bir “güçlü sunucu” satın almak değil; trafik artışını katmanlara bölmek, cache’i doğru kurmak ve veritabanını bağlantı/sorgu açısından kontrol altında tutmaktır. Kampanya öncesi TTFB, 5xx ve veritabanı bağlantı/slow query metriklerini hedef eşiğe bağlayın; CDN + WAF + rate limiting kombinasyonunu aktif edin; checkout tarafında asenkronlaştırma ve rollback prosedürünü hazırlayın. Bu adımları uyguladığınızda çökme anını yaşamak yerine erken sinyallerle müdahale edersiniz.

Kampanya tarihine göre hemen aksiyon alın: önce izleme ve ölçüm (TTFB/DB), ardından cache prewarming ve CDN/WAF optimizasyonunu tamamlayın. Son olarak rollback planını feature flag/konfigürasyon üzerinden doğrulayın.