E-ticarette indirim günü çökmesini önleme: Net kapasite planı

İndirim günleri (Black Friday, kampanya haftaları) e-ticaret sitelerinde “ani trafik artışı + satın alma yoğunluğu” nedeniyle altyapının en kritik stres testi olarak çalışır. Tek bir sunucuya kurulu, tek bir veritabanı örneğine bağımlı veya önbelleklemesi zayıf sistemler bu günlerde kolayca yavaşlar ve ardından hata verir. Bu rehberde, NetKıyas perspektifiyle çökme riskini sayılabilir metriklere bağlayıp; VDS/VPS, web katmanı, uygulama katmanı, veritabanı ve CDN için net bir plan çıkaracaksınız.

Aşağıdaki başlıklarda; indirim öncesi “neyi ölçmeliyim”, indirim günü “neye göre ölçeklemeliyim”, indirim sonrası “hangi kanıtlarla düzeltmeliyim” adımlarını teknik ve uygulanabilir şekilde ele alacağız.

1) Çökmenin gerçek nedeni: trafik değil, darboğaz

İndirim gününde kullanıcılar genellikle “site açılmıyor” gibi tek bir sorunu görür. Oysa sistemde farklı darboğazlar aynı anda büyür. Bu nedenle önce arıza türünü sınıflandırmanız gerekir.

En sık görülen 5 çökme senaryosu

• Web sunucusu (Nginx/Apache) doyar: Bağlantı kuyrukları artar, 502/504 görülür.
• Uygulama katmanı yavaşlar: Node.js/Java/PHP iş parçacıkları tıkanır, yanıt süreleri uzar.
• Veritabanı (MySQL/PostgreSQL) kırılır: CPU/IO artışı, kilitlenme (locking), yavaş sorgular ve bağlantı taşması görülür.
• Önbellek (cache) boştur: Her istek uygulamaya gider, sonuçları üretmek pahalı hale gelir.
• Dış servis (ödeme/CRM/ship) bekletir: Zaman aşımı (timeout) zincirleme hata yaratır.

Bu senaryoların ortak noktası, “ani artan istek hacmi” ile birlikte sistemin kapasite sınırlarına dayanmasıdır. Planın özü, bu sınırları indirimden önce ölçmek ve “limit aşımlarında” sistemi sağlıklı biçimde yönetmektir.

İndirim öncesi ölçüm seti (net kontrol listesi)

Indirim başlamadan en az 3-7 gün önce aşağıdaki metrikleri toplayın: - P95 (95. yüzde dilim) yanıt süresi: Uygulama ve sayfa düzeyi. - Hata oranı: 4xx/5xx oranı; özellikle 502/504. - CPU ve RAM: Web + uygulama + veritabanı ayrı ayrı. - Veritabanı bağlantı sayısı: “Too many connections” gibi semptomlar var mı? - Disk I/O ve swap: Swap kullanımı varsa performans çökebilir. - Cache hit oranı: Özellikle sayfa önbelleği ve nesne önbelleği (object cache). - Önbelleği devre dışı bırakan durumlar: Query parametresi, dinamik sayfa parçaları.

Ölçmeden kapasite planlamak; tahminle yedekleme (backup) almaya benzer: sorun çıktığında işe yaramaz.

2) Net kapasite planı: indirim trafğini sayıya çevirin

Sunucunun çökmesini önlemek için en kritik adım “indirim günündeki gerçek yükü” kabaca değil, bir modelle tahmin etmektir.

Trafik modelini 3 parametreyle kurun

Aşağıdaki üç parametre indirim için yeterli netlik sağlar: 1. Seans (session) sayısı: Ortalama gün içi trafikten yola çıkın. 2. Ortalama istek sayısı (requests/session): Ürün sayfası, liste, arama, sepete ekleme gibi akışlarda. 3. Ağır istek türleri: Sepete ekleme, stok kontrolü, fiyat indirim hesaplama, ödeme başlatma.

Örneğin tipik bir model şöyle kurulur: - Günlük normal seans: 50.000 - İndirim günü çarpanı: 5x → 250.000 seans - Ortalama requests/session: 18 → 4.5 milyon istek - Ağır isteklerin oranı (sepete ekleme + stok + fiyat): %2 → 90.000 ağır istek

Bu sayıları bilmek; sadece “CPU artacak” demekten daha somuttur. Sonra bu ağır istekleri uygulama ve veritabanı tarafında ayrı düşünürsünüz.

Basit ama net boyutlandırma yaklaşımı

Tek bir hedef belirleyin: - İndirim gününde P95 yanıt süresi belirli bir eşikte kalsın. - Hata oranı %0.5 altında kalsın.

Bu hedefe giden yol, katmanları ayırarak kapasiteyi ölçeklemektir: - Web/app: yatay ölçek (birden fazla VDS/VPS veya container) + load balancer. - Veritabanı: dikey ölçek veya okuma/yazma ayrımı; gerekiyorsa geçici kaynak. - Cache: CDN + uygulama önbelleği.

3) İndirim günü için mimari: ölçeklemenin doğru yeri

İndirim gününde “tüm trafiği tek noktaya yığmak” çökme sebebidir. Bu nedenle mimarinizin ölçeklemenin yapılacağı yeri net belirlemesi gerekir.

Minimum sağlam kurulum (ölçeklenebilir)

Aşağıdaki bileşenleri kullanmak pratikte fark yaratır: - CDN (İçerik Dağıtım Ağı): Statik dosyalar (CSS/JS/resim) ve mümkünse sayfa önbelleği. - Load balancer: Trafiği birden fazla web/app düğümüne paylaştırır. - Uygulama sunucuları: PHP-FPM / Node.js workers / JVM thread sayıları kontrollü. - Veritabanı: Bağlantı havuzu + doğru indeksler. - Queue (kuyruk): Sepet/fatura/envanter gibi işlemleri senkron değil akışa bağlamak.

“Ne zaman hangi katmanı büyütmeli?”

Aşağıdaki karar tablosu, indirim başladığında hangi noktaya dokunacağınızı netleştirir.

4) VDS/VPS seçimi ve yapılandırma: çökmeden önce limitleri yönet

Burada amaç “en pahalı sunucu” değil; indirim gününde sınırları kontrollü şekilde yönetmektir. VDS/VPS tarafında şu başlıklar net fark yaratır.

Web/app katmanı için net yapılandırma

• Worker/process sayıları: Sunucunun CPU çekirdeğine göre mantıklı ayarlanmalı. Varsayılan değerler indirim gününde yetersiz kalabilir.
• Keep-Alive ve bağlantı limitleri: Nginx/Apache bağlantı yönetimi kritik.
• Sık kullanılan sayfalar için cache: Ürün listeleme, kategori sayfaları ve stoksuz varyantlar CDN ile hızlandırılmalı.
• TLS/HTTP2 ayarları: Yeni bağlantı maliyeti azalır.

Veritabanı için net hedefler

• Bağlantı havuzu (connection pool): Uygulama, DB’ye aşırı bağlantı açmamalı.
• Indeks ve sorgu planı: Stok/sipariş ekranlarında sık kullanılan sorgular için doğru indeksler şart.
• Yavaş sorgu tespiti: Indirim öncesi P95 ve “en çok çağrılan sorgular” raporlanmalı.
• Yedekleme (backup) saatleri: İndirim gününde yedek alma darboğaz yaratmayacak zamanlamada olmalı.

Ölçekleme planını “kural”a bağlayın

İndirim günü canlı ortamda manuel karar almak yerine kural koyun. Örneğin: - P95 yanıt süresi 1.8s’yi 5 dakika boyunca aşarsa → web/app instance +1. - 5xx oranı %1’i 3 dakika aşarsa → cache policy gözden geçir, heavy route’ları queue’ya al. - DB CPU sürekli %85+ ise → okuma ayrımı/çoğaltma (read replica) ve indeks optimizasyonu.

Bu kural seti, “panik aksiyon” yerine ölçümlü müdahale sağlar.

5) İndirim günü önlemleri: kontrol listesi (uygulanabilir)

Aşağıdaki listeyi indirimden önce tamamlayın. Her madde, çökme riskini belirli bir kökten azaltır.

A) Ön hazırlık (indirimden 3-7 gün önce)

• [ ] En son 7 günün P95 yanıt süresi raporunu çıkar.
• [ ] En çok yüklenen 20 endpoint/rota listesini çıkar.
• [ ] Ürün liste/kategori sayfaları için cache stratejisi netleştir.
• [ ] Sepete ekleme ve stok kontrolü gibi ağır adımlar için zaman aşımı (timeout) değerlerini kontrol et.
• [ ] Veritabanında en pahalı sorgular için indeks ve sorgu optimizasyonu yap.
• [ ] Queue altyapısı varsa uygun iş akışlarını belirle.

B) İndirim başlarken (0-2 saat)

• [ ] Load balancer health check ayarları doğru mu kontrol et.
• [ ] 5xx/latency metriklerini canlı izleyip kural setini hazır tut.
• [ ] Cache ile ilgili “beklenmedik düşüş” var mı kontrol et.
• [ ] Veritabanı bağlantı sayısı hedef dışına çıkıyor mu izle.

C) İndirim ortası (2-12 saat)

• [ ] Ağır isteklerde kuyruğa alma (queue) gerektiren senaryoları devreye al.
• [ ] Dış servis (ödeme/teslimat) timeoutlarını logla; “sistem hata” ile “servis gecikmesi” ayrımını yap.
• [ ] Gerekirse geçici kaynak (ek instance / geçici DB kaynak) kullan.

D) İndirim sonrası (kapanış + 24 saat)

• [ ] Olay sonrası rapor (postmortem): hangi metrik ne zaman sapmış.
• [ ] Loglardan en çok tetiklenen hataları çıkar: 502/504/DB connection error.
• [ ] İndirim günü boyunca çalışmayan cache kurallarını düzelt.
• [ ] Bir sonraki indirim için kapasite modelini güncelle (çarpan, heavy route oranı).

Net karşılaştırma: kapasiteyi hangi bileşen belirliyor?

Kullanıcılar genelde “kaç CPU/RAM alayım?” diye sorar. İndirim günü performansında ise asıl belirleyici çoğu zaman sistemin tek bir noktasının sınırını ne kadar hızlı aştığıdır.

Aşağıdaki tablo, e-ticaret akışlarında baskın bileşeni hızlı ayırt etmeyi sağlar:

Bu tabloya göre yatırım yapmanız gereken yer daha net olur.

Sonuç: İndirim günü çökmesini önlemek için aksiyon planı oluşturun

İndirim günü çökmesini engellemek, tek seferlik “daha güçlü sunucu” kararı değildir; ölçümle başlayıp kural bazlı ölçekleme, cache katmanı ve veritabanı bağlantı yönetimiyle ilerleyen bir süreçtir. Net bir başlangıç için bugün yapmanız gerekenler şunlar: (1) son 7 gün P95 ve 5xx metriklerini çıkarın, (2) ağır endpoint/rotaları belirleyin, (3) cache/CDN ve DB bağlantı havuzu için indirim öncesi kontrolleri tamamlayın, (4) web/app ve DB için net kural seti oluşturun.

Bu planı oluşturup indirim öncesi test ettiğinizde, sunucu çökmesi “olasılık” olmaktan çıkar; yönetilebilir bir senaryoya dönüşür.