Tedarikçiyle anlaşma imzaladığında sana bir API dokümanı verilir ve içinde genellikle tek bir satır geçer: "dakikada 60 istek". Çoğu satıcı bu satırı okur, "ben günde 200 sipariş alıyorum, sorun yok" diye düşünür ve konuyu kapatır. Sonra bir hafta sonu kampanyası yapar, aynı dakikada 40 sipariş girer, her sipariş stok sorgusu artı satın alma artı doğrulama derken üç çağrı yapar ve tedarikçi kapıyı kapatır. Günde 200 sipariş, dakikada 120 istek demektir; kota günlük değil anlıktır.
Burada asıl yanlış anlaşılan şey şu: hız sınırı bir ceza değil, tedarikçinin kendi sistemini ayakta tutma yöntemidir. Senin işin o sınırı aşmamak değil, sınırı bilerek yönetmektir. İyi kurulmuş bir e-pin satış scripti tedarikçiye rastgele saldırmaz; kendi içinde bir musluk tutar, akışı ölçer ve sınıra yaklaştığında kendi kendini yavaşlatır. Bu yazıda o muslukları nasıl kuracağını, hangi sayıları takip edeceğini ve epin yazılım tarafında hangi ayarların hayat kurtardığını anlatıyorum.
Kota Bitmez Sanıyorsun: Ama Tedarikçin Seni Saniyede Sayıyor
Kotayı doğru hesaplamanın ilk adımı, bir siparişin kaç API çağrısına karşılık geldiğini yazmaktır. Tipik bir akışta şunlar olur: sepet aşamasında fiyat sorgusu, ödeme öncesi stok kontrolü, ödeme sonrası satın alma, ardından sonuç doğrulama. Dördü de aynı kotadan düşer. Buna kataloğu güncelleyen zamanlanmış görevleri, fiyat senkronizasyonunu ve panelde birinin elle bastığı "yenile" butonunu eklediğinde tablo değişir.
Bu yüzden kota yönetimi çağrı bütçesi olarak düşünülmelidir. Bütçenin büyük kısmını satın alma çağrılarına ayırırsın, çünkü onlar doğrudan paraya dönüşür. Fiyat ve stok senkronizasyonu gibi çağrılar ise ikinci sınıf vatandaştır: yoğun saatte seyrekleşmeli, hatta tamamen durmalıdır. Bunu yapmanın yolu her çağrıya bir öncelik etiketi vermektir. Yüksek öncelikli çağrı beklemeden geçer, düşük öncelikli çağrı kotanın yüzde altmışı dolduğunda sıraya girer. Böylece sınır aşımı önce reklam bütçeni değil, sadece katalog tazeliğini etkiler.
429 Hatası Bir Arıza Değil, Bir Mesajdır
Çoğu entegrasyon 429 yanıtını genel bir hata gibi işler: kaydeder, siparişi başarısız yapar, müşteriye üzgün bir mesaj gösterir. Oysa 429 tedarikçinin sana "şu an değil, biraz sonra" demesidir. İçinde genellikle bir de talimat bulunur: Retry-After başlığı. Bu başlık saniye cinsinden ne kadar bekleyeceğini söyler ve ona uymak, tahmin yürütmekten her zaman iyidir.
Doğru davranış şudur: 429 alındığında istek başarısız sayılmaz, ertelenir. Retry-After varsa o süre kadar, yoksa artan bekleme mantığıyla beklenir. Aynı anda o tedarikçiye ait diğer bekleyen çağrılar da durdurulur; çünkü sayaç hesap bazlıdır, tek tek istek bazlı değildir. Bir çağrı sınırı gördüyse diğerleri de görecektir. Ayrıca 429 ile 403'ü kesinlikle ayırman gerekir: 429 zamanlama sorunudur, 403 yetki sorunudur ve tekrar denemek onu çözmez, sadece hesabını şüpheli hale getirir. Bu ayrımı yapmayan bir dijital ürün satış yazılımı kendi kendini bloke ettirir.
| Yanıt | Gerçek anlamı | Doğru tepki | Yanlış tepki |
|---|---|---|---|
| 429 | Anlık hız sınırı doldu | Retry-After kadar bekle, ertele | Hemen tekrar denemek |
| 403 | Yetki veya IP kısıtı | Dur, yapılandırmayı kontrol et | Döngüde denemek |
| 402 | Bakiye yetersiz | Yöneticiyi uyar, kuyruğu beklet | Siparişi iptal etmek |
| 503 | Geçici bakım | Devre kesiciyi aç, 5 dk bekle | Tüm kuyruğu boşa harcamak |
| 200 ama boş gövde | Belirsiz sonuç | Aynı anahtarla durum sorgusu | Yeni satın alma denemek |
Token Kovası Mantığını Anlamadan Kampanyaya Girmek Neden Riskli?
Hız sınırını kendi tarafında uygulamanın en sade yolu token kovası modelidir. Kovanın kapasitesi tedarikçinin izin verdiği anlık istek sayısıdır; kovaya saniye başına sabit sayıda jeton damlar. Her çağrı bir jeton harcar. Jeton yoksa çağrı bekler. Bu model hem ani yoğunluğa izin verir hem de ortalamayı sınırın altında tutar. Gerçek hayatta "patlama toleransı" dediğimiz şey tam olarak bu kova kapasitesidir.
Uygulamada iki detay kritiktir. Birincisi, kovanın tüm sunucularda paylaşılması gerekir; her işçi süreç kendi kovasını tutarsa toplamda sınırı üçe katlarsın. Bu yüzden sayaç merkezi bir yerde, örneğin tek bir tabloda atomik artırmayla tutulmalıdır. İkincisi, kovayı tedarikçi sınırının tam üstüne değil yüzde seksenine ayarlamalısın. Aradaki yüzde yirmi, senin ölçemediğin çağrılar için sigortadır: panelden elle atılan istekler, yeniden denemeler, bir de tedarikçinin sayaç penceresi ile senin saatinin arasındaki kayma.
Kota aşımına yol açan çağrıların dağılımı
- Katalog ve fiyat senkronizasyonu 40%
- Gereksiz stok sorguları 30%
- Kontrolsüz yeniden denemeler 20%
- Gerçek satın alma çağrıları 10%
Tek Tedarikçiye Bağlı Kalmanın Gizli Faturası
Kota yönetiminin en güçlü aracı aslında teknik değil ticari: ikinci tedarikçi. Aynı ürünü iki kaynaktan alabiliyorsan, birinin sınırı dolduğunda diğerine geçersin ve müşteri hiçbir şey fark etmez. Buna yönlendirme kuralı denir ve üç girdiye bakar: kalan kota, son beş dakikadaki hata oranı, birim maliyet.
Yönlendirmeyi kurarken sık yapılan hata sadece maliyete bakmaktır. En ucuz tedarikçi sürekli seçilir, kotası sürekli dolar, kuyruk sürekli bekler. Doğru kurgu şudur: maliyet birincil ölçüt olur ama kalan kota yüzde yirminin altına düştüğünde tedarikçinin ağırlığı otomatik azalır. Böylece pahalı kaynak sadece gerektiğinde devreye girer. Pinova'nın çok tedarikçili yönlendirme kurgusunu ve kota göstergelerini özellikler bölümünde inceleyebilir, lisans seçeneklerini fiyat tarafında karşılaştırabilirsin.
Kotayı Panelden Görmüyorsan Yönetemiyorsun
Hız sınırı yönetiminin en sinsi tarafı görünmez olmasıdır. Sistem sınıra dayandığında çökmez, sadece yavaşlar. Sipariş teslimatı iki saniye yerine kırk saniye alır, kimse şikayet etmez, sen de fark etmezsin; ta ki dönüşüm oranlarında açıklanamayan bir düşüş görene kadar. Bu yüzden kota, panelde sayı olarak durmak zorundadır.
Görmen gereken metrikler şunlar: tedarikçi başına son bir dakikadaki çağrı sayısı, kalan kota yüzdesi, son bir saatteki 429 sayısı, ortalama yanıt süresi ve kova nedeniyle bekletilen çağrıların sayısı. Son metrik en değerlisidir, çünkü sınıra dayanmadan önce sana haber verir: bekletilen çağrı sayısı sıfırdan farklı olmaya başladığı gün, tedarikçiyle limit artırımı konuşmanın vaktidir. Ciddi bir e-pin yazılımı bu konuşmaya elinde veriyle gider, tahminle değil.
Hız Sınırını Dostun Yapmak İçin Yedi Günlük Uygulama Planı
Birinci gün: tüm giden çağrıları tek bir istemci katmanından geçir. Ölçmediğin şeyi sınırlayamazsın, dağınık curl çağrıları varken kota yönetimi imkansızdır. İkinci gün: her çağrıyı tedarikçi, uç nokta, süre ve yanıt kodu ile logla. Üçüncü gün: logdan gerçek tepe değerini çıkar ve dokümandaki sınırla karşılaştır.
Dördüncü gün: token kovasını yüzde seksen eşiğiyle devreye al ve düşük öncelikli çağrıları etiketle. Beşinci gün: 429 için Retry-After'a uyan erteleme mantığını ekle, 403'ü tekrar deneme kapsamından çıkar. Altıncı gün: stok ve fiyat sorgularına kısa ömürlü önbellek koy; aynı ürün için otuz saniye içinde ikinci sorguyu yapmak çoğu zaman gereksizdir. Yedinci gün: panel göstergelerini aç ve eşik uyarısı kur. Bu plan tamamlandığında sistemin sınırı aşmayı bırakır, sınıra yaklaştığını sana önceden söyler.
| Kontrol maddesi | Amacı | Hazır sayılma ölçütü |
|---|---|---|
| Tek merkezi API istemcisi | Tüm çağrıları ölçülebilir kılar | Kodda dağınık istek yok |
| Paylaşımlı token kovası | Çok işçili kurulumda sınırı korur | Sayaç atomik ve merkezi |
| Retry-After uyumu | Gereksiz aşımı engeller | 429'da başlık okunuyor |
| Çağrı öncelik etiketi | Satışı senkronizasyona kurban etmez | Düşük öncelik yoğunda duruyor |
| Kısa ömürlü önbellek | Stok ve fiyat çağrısını azaltır | 30 sn içinde mükerrer sorgu yok |
| Kalan kota göstergesi | Erken uyarı sağlar | Panelde canlı görünüyor |
| Yedek tedarikçi kuralı | Sınır dolunca satışı sürdürür | Otomatik geçiş test edildi |
Tedarikçi dokümanları çoğu zaman güncel değildir. Kendi loglarındaki ilk 429 anına ait çağrı sayısı, gerçek sınırın en dürüst göstergesidir.
Kota yönetimi kutudan çıktığı gibi çalışsın
Merkezi istemci, paylaşımlı kova, öncelikli çağrı ve tedarikçi yönlendirme mantığı Pinova'da hazır gelir. Sen sadece sınırları girersin.
Tedarikçim hız sınırını dokümanda yazmıyorsa ne yapmalıyım?
Kademeli test yap: düşük bir kovayla başla, haftalık olarak yüzde yirmi artır ve ilk 429 geldiğinde o andaki çağrı sayısını gerçek sınır kabul et. Sonra yüzde seksenine geri çek.
Her çağrıyı önbelleğe almak riskli değil mi?
Satın alma çağrısı asla önbelleğe alınmaz. Önbellek yalnızca fiyat, katalog ve stok gibi okuma çağrıları içindir ve ömrü kısa olmalıdır.
Kota dolduğunda müşteriye ne göstermeliyim?
Hata değil, hazırlanıyor durumu göster. Çağrı ertelenmiş demektir, sipariş kaybolmamıştır; bu yüzden mesaj da kayıp hissi vermemelidir.
Birden fazla mağaza aynı tedarikçi hesabını kullanırsa kota nasıl bölünür?
Sayaç hesap bazlı olduğu için kovayı mağaza başına değil hesap başına tutmalısın. İstersen mağazalara ağırlık verip aynı kovadan pay ayırabilirsin.
Hız sınırı yönetimi, tedarikçiyle ilişkini iyileştiren nadir teknik konulardan biridir: sınıra saygı gösteren entegrasyonlar daha yüksek limitler alır, öncelikli destek görür ve kampanya dönemlerinde daha rahat nefes alır. Kendi kurulumunda bu göstergelerin nasıl durduğunu merak ediyorsan canlı demo içindeki tedarikçi ekranını açıp kalan kota, bekletilen çağrı ve yönlendirme kurallarını kendi tedarikçi listenle kıyaslayarak başlayabilirsin.