Çoğu işletme yeniden denemeyi bir iyilik sanır: "hata aldıysa tekrar dener, olur biter". Panelde bir "tekrar dene" butonu vardır, arıza anında ona basılır, bazen çalışır. Oysa yeniden deneme bir buton değil bir politikadır; ne zaman, kaç kez, hangi aralıkla ve hangi koşulda denenmeyeceğini tanımlamadan kurulan her tekrar mekanizması, çözdüğü sorundan daha büyük bir sorun üretir.
Doğrusu şu: kontrolsüz tekrar deneme, tedarikçiyi yorar, kotanı tüketir, aynı kodu iki kez satın almana yol açar ve arıza anında sistemini kendi kendine boğar. Buna karşılık iyi tasarlanmış bir politika, müşteri hiçbir şey fark etmeden geçici arızaları yutar. Kullandığın dijital ürün satış scripti bu iki uçtan hangisine yakınsa operasyon maliyetin de ona göre şekillenir. Aşağıda politikanın bileşenlerini tek tek açıyorum: aralık, eşik, sınır, kimlik ve durdurma koşulu.
Her hata tekrar denemeyi hak eder mi?
Hayır ve bu sorunun cevabı politikanın temelidir. Tekrar deneme yalnızca sonucun değişebileceği hatalarda anlamlıdır. Zaman aşımı, geçici sunucu hatası, hız sınırı ve ağ kopması bu gruptadır. Buna karşılık geçersiz ürün, yetkisiz erişim, kapalı hesap veya reddedilen iş kuralı gibi durumlarda yüz kez denesen sonuç aynıdır; sadece log şişer.
Bu yüzden politikanın ilk maddesi bir izin listesidir: hangi hata sınıfları tekrar denenebilir, hangileri asla. Bu ayrım yazılı olmadığında geliştirici sezgiyle karar verir ve sezgi her arızada farklı davranır. Olgun bir e-pin satış yazılımı bu listeyi yapılandırma seviyesinde tutar; kod değiştirmeden davranış değiştirebilirsin.
Aralık nasıl hesaplanır: sabit mi artan mı?
Sabit aralık en kolay çözümdür ve en kötü davranıştır. Tedarikçi yoğunluk yüzünden hata veriyorsa, her iki saniyede bir aynı isteği göndermek yoğunluğu artırır. Doğru yaklaşım artan aralıktır: birinci deneme 2 saniye sonra, ikinci 6 saniye, üçüncü 18 saniye. Böylece sistem, tedarikçiye toparlanma alanı bırakır.
Buna bir de rastgele sapma eklenmelidir. Aynı anda hata alan yüz siparişin hepsi tam olarak altıncı saniyede tekrar denerse, tedarikçiye yeniden aynı dalga çarpar. Aralığa yüzde yirmilik rastgelelik katmak bu dalgayı dağıtır. Küçük bir detay gibi görünür ama kampanya saatlerinde tedarikçinin seni engellemesi ile engellememesi arasındaki farkı yaratır. İyi bir e-pin scripti bu sapmayı varsayılan olarak uygular.
| Politika tipi | Aralık deseni | Maks. deneme | Uygun durum | Yan etki |
|---|---|---|---|---|
| Sabit aralık | 3 sn, 3 sn, 3 sn | 3 | Çok kararlı tedarikçi | Yoğunluğu artırır |
| Artan aralık | 2 sn, 6 sn, 18 sn | 3 | Genel kullanım | Süre uzar |
| Artan + sapma | 2-2,4 / 6-7,2 / 18-21 sn | 3 | Kampanya trafiği | Öngörü zorlaşır |
| Kuyruk tabanlı | Sıraya al, işçi dener | 5 | Uzun süren arıza | Altyapı gerekir |
| Tek deneme + alternatif | 1 deneme, sonra kaynak değiştir | 1 | Çoklu tedarikçi havuzu | Kaynak yönetimi şart |
Kaç deneme yeterli ve ne zaman durmalı?
Pratikte üç deneme, geçici hataların büyük bölümünü çözer. Dördüncü ve sonrası, çözüm olasılığı düşük ama maliyeti yüksek denemelerdir. Bu yüzden deneme sayısını değil toplam süre bütçesini sınır kabul etmek daha sağlıklıdır. Örneğin "bu sipariş için en fazla 40 saniye eşzamanlı deneme yapılır, sonrasında kuyruğa alınır" kuralı hem müşteriyi hem sistemi korur.
Süre bütçesi dolduğunda sipariş kaybolmaz; arka plan kuyruğuna geçer ve müşteriye "işlemin arka planda sürüyor, sonuç e-postana gelecek" bilgisi verilir. Bu geçiş, dönüşüm oranını koruyan en değerli hamlelerden biridir. Pinova'da eşzamanlı deneme penceresi ile arka plan kuyruğu ayrı ayrı yapılandırılır; müşteri ekranda bekletilmez, sipariş de iptal edilmez.
Denemelerin hangi aşamada başarıya döndüğü
- İlk tekrar denemede 50%
- İkinci denemede 24%
- Arka plan kuyruğunda 16%
- Hiç çözülmeyen 10%
Aynı siparişi iki kez satın almamanın tek yolu
Yeniden denemenin en büyük riski çift teslimattır. İlk istek tedarikçiye ulaşmış ve işlenmiş olabilir; sana yanıt dönmediği için sistem tekrar dener ve ikinci kod da düşer. Müşteri iki kod alır, sen iki kere ödeme yaparsın, fark genelde aylar sonra keşfedilir. Bunu engelleyen tek mekanizma istek kimliği ile eşsizlik garantisidir.
Her sipariş için tek bir kimlik üret ve tüm denemelerde aynı kimliği gönder. Tedarikçi bu kimliği destekliyorsa ikinci istek yeni işlem açmaz, mevcut işlemin sonucunu döner. Desteklemiyorsa, tekrar denemeden önce mutlaka durum sorgusu yap. Kimlik yoksa ve sorgu da yoksa, tekrar deneme mekanizman aslında bir çift alım üreticisidir. Bu konuda yazılımın çekirdek davranışını özellikler bölümünden doğrulayabilirsin.
Tekrar deneme, eşsiz istek kimliği olmadan asla açılmaz. Kimlik yoksa önce durum sorgusu, sonra karar; doğrudan yeniden gönderme yok.
Alternatif tedarikçiye ne zaman geçmeli?
Çoklu kaynakla çalışıyorsan yeniden deneme stratejisi değişir. Aynı kaynağa üç kez ısrar etmek yerine, bir kez dene ve ikinci denemeyi alternatif kaynakta yap. Bu yaklaşım hem süreyi kısaltır hem tek kaynak arızasında tüm satışın durmasını engeller. Ancak burada dikkat edilmesi gereken nokta maliyettir: alternatif kaynağın alış fiyatı yüksekse, her geçişte kâr marjın erir.
Bu yüzden kaynak sıralaması sabit değil kurallı olmalı: birincil kaynak fiyat avantajlı, ikincil kaynak hızlı, üçüncül kaynak pahalı ama garantili. Sipariş tutarı ve müşteri segmentine göre hangi kaynağa kadar inileceğine karar verebilirsin. Bir dijital ürün satış yazılımı bu kararı yapılandırma ile verebiliyorsa, kâr marjını arıza anında bile koruyabilirsin.
Politikanı canlıya almadan önce neleri test edeceksin?
Yeniden deneme politikası ancak arıza altında test edilirse gerçektir. Normal koşullarda her şey çalışır; kritik olan tedarikçinin yavaşladığı, zaman aşımı verdiği ya da yarım yanıt döndürdüğü anlardır. Bu senaryoları yapay olarak üretmeden canlıya çıkmak, politikayı müşterilerinle test etmek anlamına gelir.
Aşağıdaki liste, gerçek trafiğe açmadan önce doğrulaman gereken maddeleri veriyor. Hepsini geçen bir kurulum, arıza günlerinde fark yaratır.
| Test / kontrol | Simüle edilen durum | Beklenen davranış | Sonuç |
|---|---|---|---|
| Zaman aşımı testi | Yanıt 30 sn gecikir | Artan aralıkla 3 deneme | Zorunlu |
| Yarım yanıt testi | Bağlantı ortada kopar | Durum sorgusu, tekrar yok | Zorunlu |
| Eşsizlik testi | Aynı kimlik 2 kez gider | Tek teslimat üretilir | Zorunlu |
| Hız sınırı testi | 429 yanıtı döner | Bekle ve kuyruğa al | Zorunlu |
| Kalıcı hata testi | Geçersiz ürün kodu | Hiç denemeden iptal | Zorunlu |
| Kaynak geçiş testi | Birincil kaynak kapalı | İkinciden teslim | Önerilir |
| Süre bütçesi testi | 40 sn dolar | Arka plan kuyruğuna geçiş | Önerilir |
Arızayı müşterine hissettirmeyen bir akış kur
Pinova; artan aralıklı tekrar, süre bütçesi, eşsiz istek kimliği, arka plan kuyruğu ve kurallı kaynak geçişini tek panelden yönetilebilir hale getirir.
Kaç kez tekrar denemek doğru?
Eşzamanlı olarak üç deneme çoğu senaryo için yeterlidir. Daha fazlası gerekiyorsa sipariş arka plan kuyruğuna alınmalı; müşteriyi ekranda bekletmek dönüşümü düşürür.
Tekrar deneme müşteriye ek ücret yansıtır mı?
Hayır. Tekrar denemeler tek sipariş kapsamındadır ve müşteriden tek tahsilat yapılır. Ek maliyet ancak eşsizlik kontrolü yoksa senin tarafında çift alım olarak doğar.
Zaman aşımı süresini kısa mı uzun mu tutmalıyım?
Tedarikçinin gerçek yanıt süresine göre ayarla. Çok kısa süre başarılı işlemleri hata sayar, çok uzun süre müşteriyi bekletir. 10-15 saniye çoğu TR tedarikçisi için dengeli bir başlangıçtır.
Arka plan kuyruğu müşteri deneyimini bozar mı?
Aksine korur. Süre ve garanti içeren net bir bilgi verildiğinde müşteri bekler; alternatifi olan anlık iptal, satışı tamamen kaybetmektir.
Yeniden deneme politikası, işletmenin arıza karşısındaki refleksini yazıya dökme işidir. İzin listesi, artan aralık, süre bütçesi, eşsiz kimlik ve kurallı kaynak geçişi bir arada kurulduğunda tedarikçi kaynaklı arızalar müşteri şikâyetine dönüşmeden kapanır. Bu politikanın panel üzerinde nasıl yapılandırıldığını görmek için canlı demo içinde bir arıza senaryosu dene, ardından lisans adımına geç.