Çoğu satıcı kampanya gecesini bir sunucu hikâyesi sanır. "RAM'i iki katına çıkardım, CPU'yu artırdım, artık dayanır" diye düşünür. Sonra indirim saat 20:00'de açılır, ilk on dakikada sayfa açılış süresi üç saniyeye tırmanır, sepetler boşalır, ödeme dönen ama kod teslim edilmeyen siparişler birikmeye başlar. Panele girdiğinde CPU kullanımı %40'ta durur. Yani sunucu boşta, site yine de nefes alamıyordur. İşte bu çelişki, ölçekleme konusunda yanlış yere baktığının en net kanıtıdır.
Gerçek şu: yoğun dönemde bir e-pin satış scripti kapasite yüzünden değil, sıralama yüzünden çöker. Aynı stoğa aynı saniyede yüzlerce istek dokunduğunda darboğaz işlemcide değil, veritabanı kilidinde, ödeme sağlayıcısının yanıt süresinde ve teslimat kuyruğunda oluşur. Bu yazıda donanım almadan önce yapılması gereken mimari düzenlemeleri, kampanya öncesi 72 saatlik tatbikat planını ve kesintiyi satışa çevirmenin yolunu anlatıyoruz. Amaç, aynı parayla iki kat sipariş kaldıran bir dijital ürün satış yazılımı düzeni kurmak.
Çoğu site kampanyada çökmez, sırayla teslim edemez hâle gelir
Bir kampanya anını yavaş çekimde izlersen olay şöyle akar: kullanıcılar ürün sayfasına yığılır, çoğu aynı anda "Satın Al" der, ödeme sağlayıcısına yönlenir, saniyeler içinde geri döner ve hepsi aynı stok tablosundaki aynı satırlara dokunur. Veritabanı bu noktada seni korumak için satırları kilitler. Kilit doğru davranıştır; sorun, kilidi bekleyen isteklerin PHP işçilerini meşgul tutmasıdır. İşçi havuzu doldukça yeni gelen ziyaretçi sıraya girer, sıra uzadıkça zaman aşımı başlar.
Bu yüzden ilk sorun "site yavaş" değil, "sistem iş bitiremiyor". Ölçüm alırken bak: ortalama yanıt süresi değil, 95. yüzdelik ve kilit bekleme süresi anlamlıdır. Ortalama seni yanıltır, çünkü ana sayfa hızlı yanıt verirken ödeme sonrası teslimat adımı onlarca saniye bekliyordur. İyi kurulmuş bir epin yazılım mimarisinde ödeme onayı ile kod teslimi birbirinden ayrılır; kullanıcı "siparişin alındı, kodun hazırlanıyor" ekranını saniyenin altında görür, teslimat arka planda sıralı biçimde tamamlanır.
Ölçeklemeye nereden başlamalısın: kuyruk mu, sunucu mu?
Sıralama nettir ve tersine çevirmek para yakmaktır. Önce eşzamanlılık davranışını düzelt, sonra önbelleği kur, en son kaynak ekle. Sebebi basit: bozuk eşzamanlılık modeline sunucu eklemek, aynı kilide daha fazla istemci gönderdiğin için durumu kötüleştirebilir. Dört uygulama sunucusu, tek veritabanındaki aynı stok satırına dört kat daha hızlı saldırır.
Pratik adım sırası şöyle olur: stok düşümünü tek bir atomik işlemde topla, teslimatı kuyruğa al, oturum ve sepet verisini uygulama belleğinden çıkarıp paylaşımlı bir katmana taşı, ürün listelerini kısa ömürlü önbellekle sun, statik varlıkları kenar ağına ver. Bu beş adımı tamamladıktan sonra ölçtüğün darboğaz hâlâ kaynak tarafındaysa artık sunucu büyütmek anlamlıdır. Pinova'nın altyapı özellikleri tam bu sırayı varsayarak tasarlandı; kuyruk ve kilit yönetimi panelden görünür hâlde durur.
| Eşzamanlı aktif kullanıcı | Tipik darboğaz | Yanlış çözüm | Doğru müdahale |
|---|---|---|---|
| 0 - 150 | Sorgu sayısı, N+1 listeleme | Sunucu yükseltmek | Sorgu birleştirme, liste önbelleği |
| 150 - 600 | PHP işçi havuzu tükenmesi | RAM eklemek | İşçi/bellek dengesi, yavaş uç noktaları ayırmak |
| 600 - 2.000 | Stok satırı kilit beklemesi | Sunucu çoğaltmak | Atomik stok düşümü + teslimat kuyruğu |
| 2.000 - 6.000 | Ödeme/sağlayıcı API gecikmesi | Zaman aşımını uzatmak | Devre kesici, yeniden deneme, asenkron teslim |
| 6.000+ | Veritabanı okuma yükü | Her şeyi önbelleğe almak | Okuma kopyası, yazma/okuma ayrımı |
Stok kilidi: aynı kodu iki kişiye satmanın matematiği
Kampanyada en pahalı hata çöküş değil, çift satıştır. Klasik hata şu akışta gizlidir: önce stok okunur, sonra PHP tarafında kontrol edilir, ardından güncelleme yazılır. Okuma ile yazma arasındaki milisaniyelerde ikinci bir istek aynı kodu görür. Normal günde bu boşluk hiç yakalanmaz; kampanyada saniyede yüz istek varken kaçınılmaz hâle gelir. Sonuç: aynı e-pin iki müşteriye gider, biri şikâyet eder, itibar zedelenir.
Çözüm, kararı veritabanına bırakmaktır. Stok satırını çekerken kilitle, koşulu güncelleme cümlesinin kendi içine koy ve etkilenen satır sayısı sıfırsa siparişi "stok yok" diye kapat. Böylece kontrol ile yazma tek atomik adıma iner. İyi bir e-pin scripti bunu ek bir tekillik anahtarıyla destekler: her kod kaydı yalnızca bir sipariş kimliğine bağlanabilir, ikinci bağlama denemesi veritabanı seviyesinde reddedilir. Bu, uygulama kodun hata yapsa bile çift satışı imkânsız kılar.
Kampanya gecesi yaşanan aksaklıkların kaynak dağılımı
- Veritabanı kilit/bekleme 45%
- İşçi havuzu tükenmesi 25%
- Sağlayıcı API zaman aşımı 20%
- Ağ ve kenar katmanı 10%
Sağlayıcı API'si seni yavaşlatınca ne olur?
Otomatik teslimatta kodu kendi havuzundan değil bayi API'sinden çekiyorsan, kampanya gecesi senin sitenin hızı sağlayıcının hızına bağlanır. Sağlayıcının yanıtı 800 milisaniyeden 9 saniyeye çıktığında, teslimatı senkron yapan bir kurulumda her sipariş bir PHP işçisini 9 saniye boyunca tutar. Yüz eşzamanlı sipariş, yüz kilitli işçi demektir; site tümüyle durur. Oysa asıl arıza sende değildir.
Bunun önlemi üç parçadır. Birincisi kısa zaman aşımı: cömert davranmak değil, hızlı vazgeçmek doğru olandır. İkincisi devre kesici: sağlayıcı belirli sayıda üst üste hata verdiğinde o kanalı geçici kapatıp siparişleri kuyrukta beklet. Üçüncüsü yedek kanal ve şeffaf bildirim: kullanıcıya "kodun hazırlanıyor, e-postan ve hesap panelin bilgilendirilecek" demek, boş ekran göstermekten kat kat iyidir. Kampanya planlarında bu mimariyi baştan varsaymak, sonradan yama yapmaktan ucuzdur; paket karşılaştırmasında hangi kanal yönetimi kapsamının sana yettiğini görebilirsin.
İndirimi tek saniyede herkese açmak yerine stoğu üç dilime böl ve 20 dakika arayla aç. Aynı toplam satışı alırsın ama tepe eşzamanlılık üçte bire düşer; hiçbir donanım harcaması yapmadan kapasiteyi üç katına çıkarmış olursun.
Kampanya öncesi 72 saat: yük testi ve tatbikat
Ölçekleme bir kurulum işi değil, bir tatbikat işidir. Yük testini ana sayfada yapmak seni aldatır; çünkü ana sayfa en kolay sayfadır. Testi gerçek akış üzerinde kur: ürün sayfası, sepete ekleme, ödeme başlatma, geri dönüş, teslimat. Hedef sayıyı geçmiş kampanyanın tepe dakikasının en az iki katı olarak belirle ve testi kampanya saatine denk gelen gerçek trafiğin üzerine bindir.
Tatbikatta yalnızca "dayandı mı" sorusuna değil, bozulma biçimine de bak. Sistem çökerken kuyrukta bekleyen siparişler kayboluyor mu, iki kez teslim ediyor mu, ödeme alınıp kayıt açılmıyor mu? İyi bir dijital ürün satış scripti baskı altında yavaşlar ama veri bütünlüğünü bozmaz. Bu iki davranış arasındaki fark, kampanya sonrası iade tablosunda çok net görünür.
Kampanya sonrası: ölçeği geri almak ve rakamları okumak
Kampanya bittikten sonra iki iş kalır. İlki maliyeti geri çekmek: geçici olarak büyüttüğün kaynakları düşürmek, kuyruk işçi sayısını normale almak, kampanya için gevşettiğin önbellek sürelerini eski değerine döndürmek. Bu adımı atlayan satıcılar, ayın sonunda neden iki kat fatura geldiğini anlamaz.
İkincisi ve daha kıymetlisi ders çıkarmaktır. Tepe dakikadaki eşzamanlı sipariş sayısını, en uzun kilit beklemesini, kuyruk derinliğini ve teslimat gecikmesinin dağılımını kaydet. Bu dört sayı bir sonraki kampanyanın kapasite planını sana hazır verir; tahminle değil ölçümle çalışmaya başlarsın. Bir e-pin yazılımı seçerken bu metrikleri panelde sunup sunmadığını sor, çünkü göremediğin şeyi ölçeklendiremezsin.
| Kontrol | Neden gerekli | Kampanyaya kalan süre |
|---|---|---|
| Atomik stok düşümü doğrulandı | Çift satış ve iade riskini sıfırlar | 7 gün |
| Teslimat kuyruğa alındı | İşçi havuzunu ödeme akışına serbest bırakır | 7 gün |
| Sağlayıcı zaman aşımı + devre kesici | Dış arızanın siteyi kilitlemesini engeller | 5 gün |
| Yedek veritabanı geri yükleme denemesi | Yedeğin çalıştığını sadece deneyerek bilirsin | 4 gün |
| Gerçek akış üzerinde yük testi | Bozulma biçimini önceden görürsün | 3 gün |
| Uyarı eşikleri ve nöbet planı | Sorunu müşteri değil sen fark edersin | 2 gün |
| Kademeli stok açma takvimi | Tepe eşzamanlılığı bölerek düşürür | 1 gün |
Kampanyayı kaybedilen satış olmadan geçir
Kuyruk mimarisi, atomik stok yönetimi ve çok kanallı teslimat tek panelde hazır kurulu geliyor. Sen sadece kampanyayı planla.
Kampanya için sunucumu büyütmem yeterli olur mu?
Genellikle hayır. Kilit ve kuyruk kaynaklı darboğazlar donanımla çözülmez; hatta daha fazla uygulama sunucusu aynı stok satırına daha hızlı yüklendiği için durumu kötüleştirebilir. Önce eşzamanlılık modelini düzelt, kaynağı en son ekle.
Teslimatı asenkron yapmak müşteriyi rahatsız eder mi?
Şeffaf anlatıldığında etmez. Kullanıcı saniyenin altında sipariş onayı ve net bir durum ekranı görür, kod hazır olduğunda panel ve e-posta bildirimi gider. Bu, dakikalarca dönen boş bir yükleme ekranından çok daha az şikâyet üretir.
Kampanyada hangi metriği izlemeliyim?
Ortalama yanıt süresi yerine 95. yüzdelik yanıt süresi, veritabanı kilit bekleme süresi, kuyruk derinliği ve teslimat gecikmesi dağılımı. Bu dört sayı sorunu ortaya çıkmadan önce haber verir.
Yük testini canlı sitede yapmak riskli değil mi?
Kontrollü yapılırsa gerekli. Test siparişlerini ayrı bir ödeme kanalı ve işaretli kullanıcıyla üret, stoğu ayrı bir test ürününden düşür ve testi kampanya saatine denk getir. Sahte ortamda geçen bir test, gerçek kampanyayı garanti etmez.
Kampanya gecesi kazanılan para, o gece verilen kararlarla değil; haftalar önce kurulan kuyruk, kilit ve teslimat düzeniyle belirlenir. Bu düzenin nasıl çalıştığını okumak yerine görmek istiyorsan canlı demo üzerinden gerçek bir sipariş akışını baştan sona dene, ardından paket seçimine geçerek kendi kampanya takvimini planla.