Kampanya günü çöken sitelerin ortak özelliği, testi hiç yapmamış olmaları değil — gerçekçi olmayan bir test yapmış olmaları. Ana sayfaya 10.000 istek atmak size hiçbir şey söylemez; çünkü kampanya günü kimse ana sayfada durmaz.
Gerçekçi senaryo nasıl kurulur?
Trafiği kullanıcı yolculuğu olarak modelleyin. Tipik bir kampanya günü dağılımı şuna benzer:
| Adım | Kullanıcı oranı |
|---|---|
| Kategori / arama | %100 |
| Ürün detayı | %65 |
| Sepete ekleme | %22 |
| Ödeme adımı | %9 |
| Sipariş tamamlama | %4 |
Kritik nokta: sepet ve ödeme adımları önbelleğe alınamaz. Trafiğin %4'ü sipariş tamamlıyor olsa bile, veritabanına ve ödeme servisine giden yük buradan geliyor.
Hangi metriğe bakmalı?
Ortalama yanıt süresi yanıltıcıdır. p95 ve p99 değerlerine bakın: kullanıcıların en yavaş deneyimi, sistemin gerçek sınırını gösterir. Ayrıca hata oranını ve veritabanı bağlantı havuzu doluluğunu izleyin.
En sık çıkan darboğazlar
- Stok kontrolü: Her sepete ekleme işleminde tüm ürün tablosuna kilit atan sorgular.
- Oturum deposu: Tek bir Redis örneğinin bağlantı sınırına dayanması.
- Kampanya hesaplama: Sepette her değişiklikte tüm indirim kurallarının baştan koşması.
- Ödeme sağlayıcı: Sizin altyapınız ayakta ama bankanın sanal POS'u sizin trafiğinizi kaldıramıyor.
- Görseller: Optimize edilmemiş medya bant genişliğini tüketiyor.
Test takvimi
- 6 hafta önce: İlk temel ölçüm. Mevcut sınır neresi?
- 4 hafta önce: Tespit edilen darboğazlar giderilir.
- 3 hafta önce: Hedef trafiğin 2 katıyla test.
- 1 hafta önce: Geri dönüş tatbikatı — sürüm geri alma kaç dakika sürüyor?
- Kampanya günü: Nöbet planı, canlı izleme ve önceden belirlenmiş devre kesici eşikleri.
Plan B hazır olsun
Her şey kırıldığında ne olacağını önceden kararlaştırın: ürün öneri servisi kapatılabilir mi? Yorumlar geçici olarak gizlenebilir mi? Sipariş kuyruğa alınıp arka planda işlenebilir mi? Bu kararları kriz anında değil, sakin bir odada verin.
Altyapı tarafında destek için e-ticaret çözümlerimize bakabilirsiniz.
