Tedarikçin Çöktüğünde Siparişlerin Neden Buhar Olur? E-pin Scriptinde Kimsenin Anlatmadığı "Devre Kesici" Sistemini Adım Adım İfşa Ediyorum

Çoğu satıcı tedarikçi kesintisini bir şanssızlık sanır. "API çökmüş, ne yapayım" der, destek kanalına bir duyuru yazar, akşam olur geçer. Oysa o kesinti geçtikten sonra ortaya çıkan tabloya bir bak: tahsil edilmiş ama teslim edilmemiş on beş sipariş, iki kez kod basılmış üç sipariş, bakiyesi düşürülmüş ama hiç kod almamış bir toptancı müşteri. Kesinti bir saat sürdü; enkazı temizlemek üç gün sürdü. İşin acı tarafı şu: kesintiyi sen yaratmadın, ama o enkazı senin e-pin scriptin yarattı.

Burada anlatacağım şey moda bir yazılım terimi değil, doğrudan kasa güvenliği meselesi. Ciddi bir dijital ürün satış scripti tedarikçi ayakta olduğu sürece değil, tedarikçi çöktüğünde ne yaptığıyla ölçülür. Elektrik tesisatındaki sigortayı düşün: kısa devre olduğunda evi yakmaz, devreyi keser. Yazılımda bunun adı devre kesici. Aşağıda bu mekanizmanın nasıl kurulduğunu, hangi eşiklerle çalıştığını ve kesinti sonrası mutabakatın neden devre kesicinin ayrılmaz parçası olduğunu tek tek açıyorum.

Tedarikçi Kesintisi Neden Senin Hatan Gibi Görünür?

Müşteri tedarikçinin adını bilmiyor. Sitenden PUBG UC aldı, ödeme geçti, ekranda dönen bir çark gördü ve sonra "beklenmeyen hata" yazısı. Onun gözünde suçlu tek bir taraf var: sen. Bu yüzden kesinti anında verilen teknik tepki aynı zamanda bir itibar kararıdır. Tipik bir e-pin satış yazılımı tedarikçi çağrısını doğrudan sipariş akışının içine gömer; çağrı yanıt vermezse PHP süreci bekler, bekleyen süreç havuzu doldurur, havuz dolunca sadece o tedarikçinin ürünleri değil sitenin tamamı yavaşlar. Yani tek bir sağlayıcının gecikmesi, tamamen ilgisiz bir kategoride alışveriş yapan müşterini de kaybettirir. Buna kaskad arıza denir ve e-pin sektöründe en sık görülen çöküş biçimidir. Devre kesicinin ilk işi bu zinciri kırmak: arızalı sağlayıcıyı sistemin geri kalanından izole etmek, hatayı hızlı ve öngörülebilir biçimde vermek.

Devre Kesici Nedir, Neden Her E-pin Scriptinde Olmalı?

Devre kesici, bir tedarikçi entegrasyonunun sağlık durumunu sürekli sayan küçük bir kayıt tutucudur. Her başarılı çağrı bir artı, her hata veya zaman aşımı bir eksi. Belirlediğin eşik aşıldığında kesici açılır ve o tedarikçiye giden çağrılar hiç denenmeden anında reddedilir. Bu kulağa acımasız gelir ama tam tersi: çöken bir servise yüz kez daha vurmak onun ayağa kalkmasını geciktirir, seninse tüm kaynaklarını tüketir. Pinova tarafında bu mantık her sağlayıcı için ayrı ayrı çalışır; yani bir tedarikçi kapandığında diğerleri hiç etkilenmez. Doğru kurulmuş bir epin yazılım katmanında kesici üç bilgiyi mutlaka saklar: son hata zamanı, ardışık hata sayısı ve kesicinin açıldığı an. Bu üç değer olmadan "ne zaman tekrar deneyeyim" sorusunun matematiksel bir cevabı olmaz, elle açıp kapatmak zorunda kalırsın. Elle müdahale gerektiren her mekanizma gece üçte işe yaramaz.

Üç Durum, Üç Farklı Karar: Kapalı, Yarı Açık, Açık

Kesicinin üç hali vardır ve aralarındaki geçiş kuralları sistemin karakterini belirler. Kapalı durumda her şey normaldir, çağrılar geçer, hatalar sayılır. Eşik aşılınca kesici açık duruma geçer; bu pencerede tedarikçiye tek bir istek gitmez, sipariş sıraya alınır veya alternatif sağlayıcıya yönlenir. Bekleme süresi dolduğunda kesici yarı açık hale gelir: yalnızca bir tek deneme isteği gönderilir. O istek başarılıysa sayaçlar sıfırlanır ve akış normale döner; başarısızsa pencere ikiye katlanarak yeniden kapanır. Bu üssel geri çekilme mantığı çok önemli, çünkü tedarikçi genellikle aşırı yükten çökmüştür ve sen tam ayağa kalkarken üstüne bekleyen tüm siparişleri boşaltırsan onu ikinci kez devirirsin. İyi bir e-pin satış scripti yarı açık denemeyi gerçek bir müşteri siparişiyle değil, mümkünse bakiye sorgulama gibi maliyetsiz bir uç noktayla yapar.

Zaman Aşımı Ayarlarını Yanlış Kurmak Neden Tüm Siteyi Kilitler?

Devre kesicinin en kritik ayarı aslında kesicide değil, onun altındaki HTTP istemcisindedir. Bağlantı zaman aşımını 3 saniye, yanıt zaman aşımını 8 ila 10 saniye üzerinde tutan hiçbir entegrasyon güvenli değildir. Neden? Çünkü kesici hatayı ancak zaman aşımı dolduktan sonra sayabilir. 60 saniyelik bir zaman aşımıyla üç ardışık hatanın birikmesi üç dakika sürer ve o üç dakika içinde yüzlerce istek sunucunda birikir. Yani yavaş zaman aşımı, devre kesiciyi işlevsiz bırakır. İkinci tuzak, tekrar denemeleri zaman aşımına eklemeden hesaplamaktır: 10 saniyelik zaman aşımı artı iki tekrar, en kötü senaryoda 30 saniyelik bir sipariş demektir. Bu yüzden dijital ürün satış yazılımı tarafında toplam bütçe belirlemek gerekir; siparişin uçtan uca 12 saniyeden fazla sürmeyeceğini garanti et, kalanı kuyruğa devret. Kuyruk mimarisi olmayan bir panelde kesici sadece hata mesajını hızlandırır, satışı kurtarmaz.

Kesinti Anında Müşteriye Ne Söylersin?

Teknik kesicinin bir de vitrin tarafı var ve satıcıların büyük kısmı burayı boş bırakıyor. Müşteri "Hata: 500" gördüğünde ne yapacağını bilmez; ödeme geçtiyse panikler, geçmediyse rakibine gider. Oysa üç farklı senaryoda üç farklı dil kullanmak gerekir. Ödeme henüz alınmadıysa ürünü sepette gri yapıp "şu anda satışta değil" demek en dürüst yoldur; müşteri kart bilgisini girmeden yönlendirilir, memnuniyetsizlik oluşmaz. Ödeme alındıysa asla hata gösterme; siparişi "işleniyor" durumunda tut, ekranda kesin bir taahhüt ver ve arka planda kuyruk devam etsin. Üçüncü senaryo toptancı müşteriler: onların API entegrasyonu senin panelini çağırıyor, dolayısıyla onlara insan diliyle değil doğru HTTP koduyla konuşmalısın. 503 dön, Retry-After başlığı koy, kendi kesicilerini çalıştırmalarını sağla. Bu detay bayi ilişkilerinde fark yaratır, çünkü profesyonel bayiler karşısındaki sistemin olgunluğunu tam olarak buradan okur.

Kesinti Sonrası Mutabakat: Parayı Aldın ama Kod Gitmedi

Devre kesici kesintiyi yönetir; mutabakat ise kesintinin bıraktığı belirsizliği temizler. En tehlihli durum, tedarikçiye istek gittiği ama yanıtın ulaşmadığı andır. Kod üretildi mi, üretilmedi mi bilmiyorsun. Bu soruya tahminle cevap verirsen ya müşteriye iki kod verip zarar edersin ya hiç vermeyip şikayet alırsın. Çözüm, her sipariş için tedarikçiye gönderilen benzersiz bir referans numarası üretmek ve kesinti sonrasında o referansla sorgulama yapmaktır. Sağlayıcı "bu referansla işlem yaptım" diyorsa kodu çek, teslim et; "böyle bir işlem yok" diyorsa siparişi iade et. Referans üretmeyen bir entegrasyonda mutabakat imkansızdır, elle Excel karşılaştırması yaparsın. Bu yüzden mutabakat işi bir rapor ekranı değil, mimarinin temelidir: benzersiz referans, durum sorgulama uç noktası ve kesinti sonrası otomatik tarama işi. Üçü bir aradayken sabah paneli açtığında kesintiden haberin bile olmaz, çünkü sistem geceyi kendi kendine kapatmıştır.

Tedarikçi kesintisi kaçınılmazdır; kesintinin kasana zarar vermesi değildir. Devre kesici, doğru zaman aşımı, kuyruk ve otomatik mutabakat bir araya geldiğinde sen sabah paneli açtığında sadece bir bildirim görürsün, şikayet yığını görmezsin. Bu katmanların gerçek bir panelde nasıl göründüğünü, kesici açıldığında sipariş ekranının nasıl davrandığını ve mutabakat raporunun neyi gösterdiğini merak ediyorsan canlı demo üzerinden kendin dene; ardından özellik listesine ve lisans fiyatlarına göz at.