Tedarikçi API'si 40 Saniye Cevap Vermeyince Bütün Siteni Kim Kilitliyor? E-Pin Scriptinde Zaman Aşımı Ayarlarının Konuşulmayan Tarafı

Çoğu kişi tedarikçi yavaşladığında sadece o ürünün teslimatının geciktiğini sanır. Gerçekte olan şey çok daha büyüktür: yavaş bir tedarikçi, doğru ayarlanmamış bir sistemde bütün siteyi rehin alır. Bir istek cevap bekler, arkasında ikincisi birikir, üçüncüsü PHP işçisini tutar, onuncusunda ana sayfa bile açılmaz olur. Müşteri “site çöktü” diye yazar, sen sunucuya bakarsın, işlemci rahat, bellek rahat, her şey yerinde. Çünkü sorun kaynakta değil, beklemekte.

Zaman aşımı ayarı bu yüzden teknik bir detay değil, ticari bir karardır. Kaç saniye beklemeye razı olduğunu belirlemezsen, kararı senin yerine tedarikçinin en kötü günü verir. Bu yazıda bağlantı ve okuma sürelerini neden ayrı düşünmen gerektiğini, tek bir siparişin toplam süre bütçesini nasıl kuracağını, tekrar denemenin hangi durumda faydalı hangi durumda felaket olduğunu ve yavaşlığı gecikmeye değil kuyruğa çevirerek nasıl hayatta kalacağını anlatıyorum. Hangi e-pin satış scripti ile çalışıyorsan çalış, bu çerçeve değişmez.

Bağlantı Zaman Aşımı ile Okuma Zaman Aşımını Aynı Şey Sanmak Nereye Götürür?

İki farklı bekleme vardır ve ikisi bambaşka arızaları anlatır. Bağlantı zaman aşımı, karşı tarafın kapısını çalıp açılmasını beklediğin süredir; tedarikçinin sunucusu tamamen düşmüşse ya da ağ yolu koptuysa burada takılırsın. Okuma zaman aşımı ise kapı açıldıktan sonra cevabın gelmesini beklediğin süredir; tedarikçi ayaktadır ama veritabanı boğulmuştur. Tek bir ayarla ikisini yönetmeye çalışmak, iki farklı hastalığa aynı ilacı vermektir.

Pratikte bağlantı süresi kısa olmalıdır, çünkü ağ ya vardır ya yoktur; iki üç saniye içinde el sıkışılmıyorsa beklemenin faydası yoktur. Okuma süresi ise uç noktanın işine göre değişir: bakiye sorgusu bir saniyede dönmeli, kod çekme işlemi birkaç saniye alabilir. Ciddi bir dijital ürün satış scripti bu iki değeri entegrasyon bazında ayrı ayrı tanımlamana izin verir, tek bir genel ayara mahkum etmez.

Siparişin Toplam Süre Bütçesi Yoksa Her Ayar Kağıt Üstünde Kalır

Tek tek zaman aşımı vermek yetmez, çünkü bir sipariş genellikle tek çağrı değildir. Bakiye sorgusu, stok kontrolü, satın alma, durum doğrulama... Her birine sekiz saniye verdiysen, en kötü senaryoda müşteri otuz saniyeden fazla ekranda bekler ve çoğu sekmeyi kapatır. Bu yüzden mantığı ters kurman gerekir: önce siparişin tamamına bir bütçe koy, sonra o bütçeyi adımlara paylaştır.

Bütçe düşüncesi ayrıca akıllı davranmayı mümkün kılar. İlk iki adım beklenenden uzun sürdüyse, geriye kalan bütçe azalmıştır ve son adıma daha kısa bir süre tanınır. Bütçe tükendiğinde sipariş hata vermez; “işleniyor” durumuna geçer ve arka planda takip edilir. Böylece e-pin yazılımı müşteriye beklemek yerine bir söz verir ve o sözü kuyrukta tutar.

Tekrar Denemek Ne Zaman İlaç, Ne Zaman Zehir?

Tekrar deneme okuma amaçlı çağrılarda ilaçtır, para harcayan çağrılarda zehirdir. Bakiye sorgusu zaman aşımına uğradıysa tekrar sormanın zararı yoktur. Ama kod satın alma isteği zaman aşımına uğradıysa, istek karşı tarafa ulaşmış ve işlenmiş olabilir; tekrar denersen aynı siparişe ikinci kez kod satın alırsın ve parayı iki kez ödersin. Buradaki tek güvenli yol, tedarikçinin kabul ettiği bir tekillik anahtarı göndermek ve zaman aşımından sonra satın almayı tekrar etmek yerine durumu sorgulamaktır.

Tekrar denemelerin arasına artan bekleme koymak da şarttır. Yavaşlayan bir sisteme aynı anda üç kat istek yağdırmak, onu tamamen düşürmenin en hızlı yoludur. Gecikmeyi katlayarak arttır, üzerine küçük bir rastgelelik ekle ve toplam deneme sayısını ikiyi geçirme. Olgun bir epin yazılım kurgusunda bu davranış entegrasyonun kendi ayarında yazılıdır, geliştiricinin hatırlamasına bırakılmaz.

Zaman Aşımı Sonrası Sipariş Hangi Durumda Kalmalı?

En pahalı hata, zaman aşımını başarısızlık saymaktır. Tedarikçiye ulaşan ama cevabı dönmeyen bir satın alma isteği çoğu zaman gerçekleşmiştir. Siparişi iptal edip müşteriye para iade ederseniz, tedarikçide ödenmiş bir kod kalır ve o kod kimseye teslim edilmez; zararı sen yazarsın. Doğru yaklaşım, bu siparişi belirsiz diye işaretlemek ve arka plan işçisinin tedarikçi durum sorgusuyla gerçeği öğrenmesini beklemektir.

Bu yüzden sipariş durumları arasında mutlaka “doğrulanıyor” gibi bir ara basamak bulunmalıdır. Müşteriye gösterilen mesaj da netleşir: kodun hazırlanıyor, en geç birkaç dakika içinde panelinde ve mailinde olacak. Beklemenin adı konduğunda müşteri sabreder; adı konmadığında destek kanalını doldurur. Bu tür durum yönetiminin bir e-pin satış yazılımı içinde hazır gelmesi, sonradan yazılmasından çok daha sağlıklıdır.

Yavaşlığı Nasıl Ölçersin ve Hangi Eşikte Alarm Çalmalı?

Ortalama yanıt süresi yanıltıcı bir ölçüdür; yüz çağrıdan doksan beşi hızlıysa ortalama güzel görünür, ama sana zarar veren o beş çağrıdır. Bu yüzden dilim değerlerine bakılır: çağrıların yüzde doksan beşi kaç saniyede dönüyor, en yavaş yüzde biri nerede duruyor. Alarm eşiğini de buna göre koyarsın. Bir uç noktanın yavaş dilimi normalinin iki katına çıktığında haber alman gerekir, müşteri yazdığında değil.

Her entegrasyon için tek bir panelde toplanmış üç sayı yeterlidir: yavaş dilim süresi, zaman aşımı oranı ve belirsiz kalan sipariş sayısı. Bu üç sayı tedarikçinin sağlığını sana her gün özetler; hangi tedarikçiyi yedeklemen gerektiğini, hangisiyle konuşman gerektiğini ve hangi ürünü geçici olarak kapatmanın daha akıllı olduğunu buradan görürsün. Teknik ayrıntıların ürün tarafında nasıl karşılandığını özellikler bölümünde inceleyebilirsin.

Zaman aşımı ayarı, tedarikçine duyduğun güvenin sayıya dönüşmüş halidir. Bu sayıları bilinçli koyduğun gün, yavaşlayan bir uç nokta artık kriz değil sadece bir bildirim olur. Kuyruklu teslimat, doğrulama durumları ve entegrasyon bazlı süre ayarlarının gerçek bir panelde nasıl göründüğünü merak ediyorsan canlı demo üzerinde bir sipariş oluşturup akışın her adımını kendin izleyebilirsin.