Kampanya gecesi yaklaşırken çoğu işletme sahibinin aklına gelen ilk şey aynıdır: "Sunucumu büyütsem yeter." Hosting paketini iki katına çıkarırsın, RAM eklersin, belki bir CDN açarsın ve rahat bir nefes alırsın. Sonra saat 20:00 olur, kampanya duyurun yayına girer, ilk beş dakikada sipariş sayısı normalin on katına çıkar ve sistem gerçekten çökmez — ama daha kötüsü olur. Siparişler düşer, para tahsil edilir, kodlar teslim edilmez. Bir kısmı iki kere teslim edilir. Panelde stok 40 görünürken elinde 12 kod vardır.
İşte kimsenin açıkça söylemediği şey şu: kampanya gecesi bir donanım testi değildir, bir eşzamanlılık testidir. Aynı saniyede aynı e-pini almaya çalışan 300 kişi varken sorun sunucunun kalbi değil, yazılımın karar sırasıdır. Sağlam bir e-pin satış scripti bu sırayı baştan kurar; zayıf bir kurulum ise sadece normal günlerde çalışıyormuş gibi görünür. Bu yazıda kampanya gecesinin gerçekte hangi katmanda kaybedildiğini, hangi sırayla hazırlık yapılması gerektiğini ve Pinova gibi bir e-pin yazılımı kullanırken hangi ayarların hayat kurtardığını tek tek açıyorum.
Çoğu kişi kampanya gecesini "sunucu gücü" sorunu sanır — asıl darboğaz nerede?
Bir kampanya gecesinde istek trafiğinin büyük kısmı okuma isteğidir: ürün sayfası, kategori, sepet görüntüleme. Bunlar önbelleğe alınabilir ve çoğu dijital ürün satış scripti bunu zaten yapar. Gerçek yük ise yazma tarafındadır: sipariş oluştur, stoktan kod ayır, ödemeyi işaretle, teslimatı kaydet, bakiyeyi düş. Bu beş işlem tek bir bütün olarak başarılı ya da başarısız olmalıdır. Aradan biri yarım kalırsa ortaya "hayalet sipariş" çıkar.
Bu yüzden hazırlık yaparken ilk sorun şudur: senin kurulumunda sipariş oluşturma işlemi tek bir işlem bloğu içinde mi çalışıyor, yoksa beş ayrı adım olarak sırayla mı yürüyor? İkincisi ise her adım arasında bir kaza penceresi var. Pinova tarafında sipariş-stok-teslimat üçlüsünün tek transaction içinde kilitlenerek yürütülmesi, gecenin en kritik ayarıdır. Sunucuyu büyütmek bu pencereyi kapatmaz; sadece daha hızlı bozulmanı sağlar.
Stok kilidi yoksa aynı e-pini kaç kişiye satarsın?
Cevap acı: teorik olarak eşzamanlı istek sayısı kadar. Kod havuzundan "ilk boş kaydı seç, sonra satıldı olarak işaretle" mantığıyla çalışan bir yapıda, iki istek arasındaki mikrosaniyelik boşlukta iki müşteri de aynı kodu okur. Normal bir günde bu neredeyse hiç olmaz, çünkü siparişler arasında saniyeler vardır. Kampanya gecesinde ise saniyede onlarca sipariş gelir ve olasılık kesinliğe döner.
Doğru yöntem, kodu okurken satır bazında kilit almak ve kodu "rezerve" durumuna alıp ancak ödeme onayından sonra "teslim edildi" durumuna geçirmektir. Üç durumlu bir kod yaşam döngüsü — boşta, rezerve, teslim — kampanya gecesinin sigortasıdır. Ayrıca rezerve kodlar için zaman aşımı tanımlamalısın: ödeme 15 dakikada tamamlanmazsa kod havuza geri dönmeli. Yoksa sabaha karşı stoğun "tükenmiş" görünür, oysa yüzlerce kod ödenmemiş sepetlerde asılı kalmıştır.
| Katman | Normal gün davranışı | Kampanya gecesi riski | Doğru ayar |
|---|---|---|---|
| Stok havuzu | Sorunsuz, sıralı okuma | Aynı kodun çift satışı | Satır kilidi + rezerve durumu |
| Ödeme dönüşü | Anında callback | Callback gecikmesi, mükerrer bildirim | Idempotent işlem anahtarı |
| Tedarikçi API | 0,4 sn yanıt | Timeout ve yarım teslimat | Kuyruk + yeniden deneme |
| E-posta/SMS | Senkron gönderim | Gönderim kuyruğu sipariş akışını kilitler | Asenkron iş kuyruğu |
| Panel raporları | Canlı sorgu | Ağır sorgular veritabanını yorar | Özet tablo, 60 sn önbellek |
| Oturum yönetimi | Dosya tabanlı | Disk I/O tıkanması | Bellek tabanlı oturum deposu |
Ödeme sağlayıcı seni aniden neden "şüpheli" görür?
Kampanya gecelerinin en sinsi sürprizi ödeme tarafından gelir. Normalde günde 80 işlem geçen bir hesabın bir saatte 600 işlem geçmesi, risk motorları için anomali demektir. Sonuç: işlemler yavaşlar, bazıları manuel incelemeye düşer, en kötü senaryoda geçici bir limit uygulanır. Bunu engellemenin yolu teknik değil, iletişimsel: kampanya tarihini ve beklediğin işlem hacmini sağlayıcına önceden bildirmek.
Teknik tarafta ise iki şeye ihtiyacın var. Birincisi, ödeme dönüş bildirimlerinin idempotent işlenmesi: aynı işlem için ikinci kez bildirim geldiğinde ikinci bir teslimat tetiklenmemeli. İkincisi, tek sağlayıcıya bağımlı kalmamak. Yedek bir ödeme yöntemi tanımlı olduğunda birinci kanal tıkandığında satış tamamen durmaz. İyi kurgulanmış bir e-pin satış yazılımı ödeme yöntemlerini bağımsız modüller olarak tutar; birini kapatmak diğerini etkilemez.
Kampanya gecesi arıza kayıtlarının kaynak dağılımı
- Stok ve teslimat mantığı 45%
- Ödeme dönüş/callback 25%
- Tedarikçi API gecikmesi 20%
- Sunucu kaynakları 10%
Kuyruk mimarisi: teslimatı satıştan ayırmadıysan geceyi kaybettin
Bir müşteri ödemeyi tamamladığında ona gösterilecek şey "siparişin alındı, kodun birkaç saniye içinde panelinde" mesajı olabilir. Ama pek çok kurulumda ödeme onayı ile birlikte aynı istek içinde tedarikçiye bağlanılır, kod çekilir, e-posta gönderilir ve SMS atılır. Bu zincirin herhangi bir halkası yavaşlarsa müşteri beyaz ekranda bekler, sabırsızlanır, sayfayı yeniler ve ikinci bir sipariş oluşturur.
Doğru kurgu, satış işlemini teslimat işleminden ayırmaktır. Ödeme onaylandığı anda sipariş "teslimat kuyruğunda" durumuna geçer ve arka planda çalışan bir işçi süreç kodu ayırıp gönderir. Böylece kullanıcı arayüzü hiçbir zaman dış servisin hızına bağlı kalmaz. Kuyruk kurgusunun üç ayarını mutlaka gözden geçir: eşzamanlı işçi sayısı, başarısız işin kaç kez yeniden denenceği ve son denemede de başarısız olursa hangi insana bildirim gideceği.
Tedarikçi API'si yavaşladığında script ne yapmalı?
Kampanya gecesinde sadece sen yoğun değilsin; tedarikçin de yoğun. 400 milisaniyede yanıt veren bir uç nokta iki saniyeye, bazen on saniyeye çıkar. Burada yapılacak en kötü şey sınırsız beklemektir. Her isteğe net bir zaman aşımı koy, üç başarısız denemeden sonra o tedarikçiyi geçici olarak devre dışı bırak ve ikinci tedarikçiye yönlendir. Bu davranışa devre kesici denir ve gecenin en değerli özelliğidir.
Ayrıca kampanya öncesinde "elde stok" ile "API'den çekilecek stok" ayrımını netleştir. Yüksek talep beklediğin ürünlerde kampanya öncesi kod ön yüklemesi yapmak, yani kodları kendi havuzuna almak, dış servise olan bağımlılığını gecenin en kritik saatlerinde sıfıra indirir. Pinova'nın ürün bazlı tedarik kaynağı seçimi tam bu yüzden vardır: bazı ürünler yerel havuzdan, bazıları canlı entegrasyondan beslenebilir.
Kampanya bitmeden hangi 7 metriği ekranda tutmalısın?
Gece boyunca panele bakıp sadece ciroyu izlemek, arabanın camını kapatıp sadece hız göstergesine bakmak gibidir. İzlemen gereken şeyler şunlar: dakikadaki sipariş sayısı, teslimat kuyruğu uzunluğu, ortalama teslimat süresi, başarısız ödeme oranı, rezervede bekleyen kod sayısı, tedarikçi hata oranı ve düşük stok uyarıları. Bu yedi sayı, sorun büyümeden önce nerede olduğunu söyler.
Bir eşik aşıldığında ne yapacağını da önceden yaz. Kuyruk 200'ü geçerse işçi sayısını artır, tedarikçi hata oranı %10'u geçerse yedeğe geç, stok kritik seviyeye inerse ürünü otomatik olarak "tükendi" göster. Karar anında düşünmek yerine hazır bir müdahale listesinden okumak, hem hatayı hem paniği azaltır.
| Kontrol | Ne zaman | Doğrulama yöntemi | Durum |
|---|---|---|---|
| Kod havuzu yeterliliği (tahminin 1,5 katı) | Kampanyadan 48 saat önce | Ürün bazlı stok raporu | Zorunlu |
| Rezerve zaman aşımı süresi tanımlı | 72 saat önce | Test siparişi bırakıp bekle | Zorunlu |
| Ödeme sağlayıcıya hacim bildirimi | 5 gün önce | Yazılı yanıt alındı mı | Zorunlu |
| Yedek ödeme yöntemi aktif | 48 saat önce | Küçük tutarlı canlı test | Zorunlu |
| Teslimat kuyruğu işçileri ölçeklenebilir | 24 saat önce | Yük simülasyonu | Önerilir |
| Tedarikçi zaman aşımı ve devre kesici | 24 saat önce | Sahte gecikme testi | Zorunlu |
| Veritabanı yedeği ve geri dönüş planı | Kampanya günü sabahı | Yedeği farklı ortama açarak dene | Zorunlu |
| Ağır rapor sorguları geçici kapalı | Kampanya saatinde | Panel yavaşlık kontrolü | Önerilir |
Duyurduğun saatten 15 dakika önce kampanyayı küçük bir kitleye aç. Böylece gerçek trafik gelmeden önce ödeme, stok ve teslimat zincirini canlı veriyle doğrulamış olursun. Bu 15 dakika, gecenin tamamını kurtarabilir.
Kampanya sonrası: gecenin gerçek kârını nasıl ölçersin?
Sabah panele baktığında ciro yüksek görünebilir ama net tabloyu üç sayı belirler: iptal/iade edilen sipariş oranı, manuel müdahale gerektiren sipariş sayısı ve destek talebi yoğunluğu. Bir kampanya, 500 sipariş getirip 60 destek talebi üretiyorsa aslında ekibinin iki gününü de satın almış demektir. Bu maliyeti hesaba katmadan "başarılı kampanya" demek yanıltıcıdır.
Bu yüzden her kampanyadan sonra kısa bir arıza günlüğü tut: ne saatte ne bozuldu, neden bozuldu, hangi ayar değişse bozulmazdı. Üç kampanya sonra elinde kendi işletmene özel, paradan daha değerli bir dokümantasyon olur. Pinova'nın özellik seti bu günlüğü tutmayı kolaylaştıracak raporlama altyapısını hazır verir; senin işin doğru soruları sormak.
Bir sonraki kampanyaya hazır bir altyapıyla gir
Stok kilidi, teslimat kuyruğu, çoklu tedarikçi ve idempotent ödeme akışı Pinova'da kutudan çıkar. Kampanya gecesini test sahasına çevirmene gerek yok.
Kampanya gecesi için sunucumu büyütmek yeterli olur mu?
Hayır. Sunucu büyütmek okuma trafiğini rahatlatır ama çift teslimat, rezerve kilidi ve callback tekrarları gibi sorunlar yazılım mantığındadır. Önce stok kilidi ve kuyruk mimarisini doğrula, sonra kaynak artır.
Rezerve edilen kodlar ne kadar süre bekletilmeli?
Ödeme yöntemine göre 10-20 dakika uygun bir aralıktır. Havale/EFT gibi yavaş yöntemlerde süreyi ayrı tanımla, yoksa hızlı ödemelerde stoğu boşuna kilitlersin.
Tek tedarikçiyle kampanya yapılır mı?
Yapılır ama riskli. En azından yüksek talep beklediğin ürünlerde kodları kampanya öncesi kendi havuzuna çekmelisin. Böylece dış servis yavaşlasa bile teslimat durmaz.
Kampanya sırasında hangi işlemleri geçici kapatmalıyım?
Ağır rapor sorgularını, toplu e-posta gönderimlerini ve zorunlu olmayan arka plan görevlerini ertele. Veritabanı kaynağını sipariş ve teslimat akışına ayır.
Kampanya gecesi, altyapının yıl boyunca biriktirdiği tüm eksikleri tek seferde faturalandırır. İyi haber şu: bu eksiklerin neredeyse tamamı önceden bilinebilir ve doğru kurulmuş bir dijital ürün satış yazılımı ile baştan kapatılabilir. Stok kilidini, kuyruğu, devre kesiciyi ve yedek ödeme yolunu bir kez doğru kurduğunda sonraki kampanyalar birer sınav değil, sadece yoğun bir çalışma günü olur. Anlattığım akışların gerçek bir panelde nasıl göründüğünü kendi gözünle görmek istersen canlı demo üzerinden sipariş, rezerve ve teslimat zincirini adım adım deneyebilir, fiyat seçeneklerini de aynı yerden karşılaştırabilirsin.