İndirim Günlerinde E-Ticaret Çökmesini Önleyin: Net Kontrol Planı

E-ticaret sitelerinde indirim günleri, ziyaret artışının yanında ödeme, stok sorguları, kupon doğrulama ve e‑posta bilgilendirmeleri gibi eşzamanlı işlemleri de yükseltir. Sunucu çökmesi çoğu zaman “aniden kapasite bitmesi” değil; veritabanı darboğazı, önbellek yokluğu, yanlış zamanlanmış görevler ve yetersiz izleme kombinasyonudur. Bu rehberde, indirim öncesi ve sırasında uygulanacak net teknik kontrolleri; hedeflediğiniz trafiğe göre ölçek, test ve koruma mekanizmalarıyla birlikte sıralıyoruz.

İndirim çöküşlerinin 5 ana nedeni ve hızlı teşhis

İndirim günlerinde gelen talep artışı genellikle beklenenden çok daha yüksek olduğu için, sorun “sunucu açılmadı”dan önce gelir. En sık görülen sebepleri ve belirtilerini kontrol edin.

1) Uygulama katmanı darboğazı

Belirti: Sayfa yüklenirken PHP/Node/Java prosesleri artar, yanıt süreleri dakikaya döner. Queue (iş kuyruğu) birikir.

Ne yapmalısınız: - Güçlendirme yerine önce kodun darboğazını bulun. Uygulama loglarında en yavaş endpointleri tespit edin. - CPU kullanımına ek olarak “worker” sayısı limitlerini kontrol edin (ör. PHP-FPM worker sayısı, Node event loop tıkanması).

2) Veritabanı (DB) bağlantı patlaması

Belirti: MySQL/PostgreSQL CPU kullanımı yükselir, Threads_connected artar, sorgular uzar.

Ne yapmalısınız: - Uygulama bağlantı havuzu (connection pool) kullanın veya bağlantı limitlerini ayarlayın. - Kupon doğrulama, stok kontrolü ve sipariş kaydı gibi kritik işlemlerde sorguları optimize edin.

3) Önbelleklemenin yokluğu veya yanlış kullanımı

Belirti: Her istek aynı pahalı işlemleri tetikler; sipariş dışındaki sayfalarda da DB yükü çok yüksektir.

Ne yapmalısınız: - Kategori, ürün listeleme, görseller ve statik içerik için CDN + reverse proxy önbelleği kurun. - “Dinamik sayfa” yerine gereksiz dinamik üretimi azaltın; mümkün olanları cache’leyin.

4) Hizmet dış bağımlılıkların gecikmesi

Belirti: Ödeme sağlayıcısı, kargo entegrasyonu veya e‑posta servisleri yavaşlayınca tüm istekler bekler.

Ne yapmalısınız: - Timeout (zaman aşımı) ve retry stratejilerini netleştirin. - E‑posta ve kupon/stok gibi işlemleri mümkün olan yerde asenkron kuyruğa alın.

5) İzleme ve otomatik koruma olmaması

Belirti: Sorun fark edilene kadar 500/502 hataları çoğalır; geri dönüş için veri yoktur.

Ne yapmalısınız: - İndirim gününden önce metrikleri tanımlayın: CPU, RAM, disk IO, DB sorgu süresi, hata oranı, yanıt süreleri, kuyruk uzunluğu.

İndirim öncesi kapasite planı: 24 saatlik “gerçekçi yük testi” şart

İndirim günü çökmesini en hızlı azaltan adım, tahmini trafiğe göre “gerçekçi” yük testini yapmaktır. Soyut tahmin yerine senaryoyu ölçün.

Hedef trafiği ölçün: pik istek başına maliyet

Aşağıdaki adımla başlayın: - İndirim öncesi 14 günün ortalama page view (PV) / dakika ve sipariş başına ortalama istekleri çıkarın. - En pahalı 10 endpointi (ör. ürün sayfası, sepet ekle, kupon doğrula, ödeme başlat) listeleyin.

Sonra basit bir hedef belirleyin: - Pik dakikada beklenen istek sayısı (RPS) × endpointlerin ortalama süreleri = toplam yük. - Bu hedefin %30 üstünü test eşiği yapın. Örnek: 200 RPS hedefiniz varsa 260 RPS test edin.

Örnek yük testi senaryosu (stok/kupon dahil)

Gerçekçi test; sadece sayfa gezintisini değil, indirim davranışlarını da kapsamalıdır: - Ürün listesi + ürün sayfası görüntüleme - Sepete ürün ekleme - Kupon uygulama (doğrulama) - Stok kontrol akışı - Ödeme başlat (sağlayıcı çağrısını mock veya gerçek entegrasyonla kontrollü test edin)

Kritik nokta: Kupon ve stok kontrolü DB’de yoğun sorgu üretiyorsa, yük testinde bu adımlar yoksa “yanlış güven” oluşur.

Mimari düzeltmeler: Önbellek, CDN, oturum ve bağlantı limitleri

Çökme genellikle “tek bir bileşen” değil; birkaç ayarın aynı gün kötüleşmesiyle gelir. Aşağıdaki maddeler indirim günü riskini düşürür.

CDN ve önbellek katmanı ile DB yükünü azaltın

Statik içerik için CDN tek başına yeterli değildir; uygulama katmanında da cache stratejisi gerekir.

Uygulanacak net hedefler: - Statik görseller/JS/CSS: CDN üzerinden cache header’ları doğru olsun (ör. uzun max-age). - Ürün listeleme ve kategori sayfaları: “stok gibi çok sık değişen alanlar” hariç sayfanın geri kalanı cache’lenebilir. - Reverse proxy (nginx) ile sayfa bazlı cache: Kural seti oluşturun.

Oturum (session) yönetimi: aynı işi tekrar tekrar yapmayın

Belirti: Oturum verisi her istekle DB’ye gidiyor, DB yükü artıyor.

Ne yapmalısınız: - Oturumları paylaşımlı depoya taşıyın (ör. Redis). - Session store ile DB arasındaki bağlantıyı azaltın.

Bağlantı limitleri ve timeout: “bekleyen istek” birikmesini engelleyin

İndirim gününde en tehlikeli durum, thread/worker sayısı dolarken isteklerin “sonsuz beklemesi”dir.

Hedef: - Uygulama timeout değerlerini netleştirin. - DB sorgu timeout / statement timeout uygulayın. - Dış servisler için (ödeme, e‑posta, kargo) timeout ve retry’yi kontrol edin.

Veritabanını indirim gününe hazır hale getirin: MySQL/PostgreSQL kontrol listesi

DB, indirimde en çok tetiklenen darboğazdır. Basit bir “upgrade” yerine doğru öncelikleri seçin.

Bağlantı havuzu ve max connection ayarları

• Uygulama katmanı DB bağlantılarını sınırsız açmamalı.
• DB tarafında max_connections yükseltmek tek başına çözüm değildir; doğru bağlantı havuzu ve sorgu optimizasyonu şarttır.

Sorgu optimizasyonu: kupon, stok ve sepet en kritikler

Aşağıdaki sorgu türlerini özellikle inceleyin: - Kupon doğrulama (kullanım limiti, son kullanma, uygun ürün/kategori eşleşmeleri) - Stok sorgusu (ürün varyantları, sipariş rezervasyonu) - Sepet hesaplama (fiyatlandırma, indirim uygulanması)

Somut yaklaşım: - EXPLAIN/EXPLAIN ANALYZE ile planları görün. - Endeks eksikleri varsa ekleyin. - N+1 sorgularını kapatın.

Okuma/yazma ayrımı ve replika kullanımı (gerekiyorsa)

Eğer mimariniz uygunsa: - Okuma trafiği (listeleme, katalog) için read replica - Yazma trafiği (sipariş kaydı, stok rezervasyonu) için primary

Bu ayrım indirim gününde DB’nin yükünü dramatik azaltabilir. Ancak replikasyon gecikmesi satış akışını etkileyebilir; kritik akışlarda primary kullanın.

Yüksek trafikte otomatik koruma: ölçekleme, rate limit ve kuyruk

İndirim günü çökmesini engellemenin bir diğer yolu, “otomatik yavaşlatma”dır. Her şeyi aynı anda işlemek yerine sistemi kontrollü çalıştırın.

Rate limiting: kupon denemeleri ve sepet ekleme için şart

• Kupon uygulama endpoint’inde kullanıcı başına limit uygulayın.
• Aynı IP’den yoğun isteklerde 429 döndürmeyi standart hale getirin.

Bu sayede botlar veya aşırı tekrar eden tarayıcılar DB’yi kilitlemez.

Kuyruk (queue) tabanlı asenkron işler

İndirim gününde senkron iş yükünü azaltın: - Sipariş oluşturulduktan sonra e‑posta gönderimi - Fatura/rapor üretimi - Kargo entegrasyonu

Bu işleri bir queue ile ayırın (ör. Redis queue, RabbitMQ, benzeri). Ana istek sadece “sipariş kaydı” gibi kritik adımları tamamlamalıdır.

Ölçekleme stratejisi: “hızlı artır, sonra daralt”

• Container kullanıyorsanız yatay ölçekleme (autoscaling) için CPU/latency metriklerini kullanın.
• İstemci tarafında “retry” davranışını kontrol edin; agresif retry fırtınası oluşturmayın.

Net kontrol tablosu: İndirim günü öncesi yapılacaklar

Aşağıdaki tabloyu checklist gibi ele alın.

İndirim günü işletimi: İzleme, alarm, manuel müdahale

Yük testinden sonra asıl farkı, indirim günü operasyonu belirler.

Alarm kurulumunda ölçülecek metrikler

En az şu metrikleri birlikte görün: - Uygulama yanıt süresi: özellikle P95 ve P99 - Hata oranı: 4xx/5xx - CPU/RAM/IO: özellikle disk IO ve swap - DB: sorgu süresi, bağlantı sayısı, kilitlenme (lock) durumu - Kuyruk uzunluğu: asenkron işlerde birikme var mı?

İlk 15 dakikada doğru aksiyon sırası

1. 5xx patladı mı? Patladıysa hangi endpoint’te yoğunlaştığına bakın.
2. DB bağlantısı ve yavaş sorgu artışı var mı? Varsa kupon/stok akışını kısmi durdurma planınız olsun.
3. Cache çalışıyor mu? Origin hit yükseldiyse cache rule bozulmuş olabilir.
4. Kuyruk büyüyor mu? Asenkron iş birikiyorsa tüketicileri ölçekleyin.

Sonuç: İndirim öncesi 3 adımı tamamlayın, çökme riskini somut düşürün

İndirim günlerinde sunucu çökmesini engellemek; kapasite varsayımı yerine ölçüm, veritabanı darboğazını hedefleyen optimizasyon ve aşırı yükte kontrollü davranmayı sağlayan koruma gerektirir. Aksiyon planı olarak önce (1) indirim senaryosunu kapsayan yük testi, (2) kupon/stok/DB ve cache odaklı performans düzeltmeleri, (3) rate limit + zaman aşımı + kuyruk tabanlı asenkronlaştırma adımlarını tamamlayın. Bu üç adımı tamamladığınızda, indirim günü yaşanan arızaların “tesadüfi” değil “yönetilebilir” hale geldiğini net biçimde görürsünüz.

İsterseniz NetKıyas üzerinden mevcut altyapınızın (VDS/VPS/dedicated) ve kullanmakta olduğunuz kontrol paneli/stack’inizi (PHP mi Node mu, MySQL mi PostgreSQL mi) yazın; indirim senaryonuza göre hangi metrikleri önceliklendireceğinizi net bir test planına dönüştürebilirim.