Yoğun bir kampanya gecesinde siteniz normalden üç kat fazla sipariş almaya başlar, her şey yolunda gider gibi görünür — ta ki tedarikçi panelinden art arda hata dönmeye başlayana kadar. Müşteri parasını öder, kod gelmez, destek kutunuz dolar. Sorunun kaynağı çoğu zaman sitenizde değil, Turkpin veya Pinabi gibi tedarikçilerin API'lerine saniyede kaç istek attığınızdadır. Bu yazıda rate limit'in ne olduğunu, manuel entegrasyonlarda neden felakete dönüştüğünü ve Pinova'nın bunu nasıl sessizce çözdüğünü anlatıyoruz.
E-pin sitesi neden API'den "rate limit" hatası alır?
Rate limit, bir API sağlayıcısının belirli bir zaman diliminde tek bir müşteriden kabul edeceği istek sayısına koyduğu sınırdır. Turkpin, Pinabi ve benzeri tedarikçiler bu sınırı kendi sunucularını korumak, adil kullanım sağlamak ve kötüye kullanımı (örneğin bot saldırılarını) engellemek için uygular. Genellikle "dakikada 60 istek" veya "saniyede 5 istek" gibi somut bir eşik vardır ve bu eşik dokümantasyonda küçük bir dipnot olarak geçer — çoğu geliştirici entegrasyonu yaparken bunu fark etmez.
Sorun şu ki bir e-pin sitesinde tek bir "sipariş" aslında arka planda birden fazla API çağrısı doğurabilir:
- Stok/fiyat sorgulama isteği
- Bakiye kontrolü
- Sipariş oluşturma isteği
- Kod/teslimat durumu sorgulama (polling)
- Bazı entegrasyonlarda ek doğrulama çağrısı
Normal günlerde bu beş çağrı sorun yaratmaz. Ama kampanya, indirim günü veya sosyal medya paylaşımı sonrası gelen ani trafik artışında aynı anda 30-40 sipariş geldiğinde toplam istek sayısı tedarikçinin izin verdiği sınırı kolayca aşar.
429 hatası aslında ne anlatıyor?
HTTP 429 "Too Many Requests" kodu, tedarikçinin "şu an seni dinlemiyorum, biraz bekle" demesidir. Çoğu iyi tasarlanmış API bu hatayla birlikte bir Retry-After başlığı da döner — yani "şu kadar saniye sonra tekrar dene" bilgisi. Ama pratikte iki büyük problem çıkar:
- Her tedarikçi bu bilgiyi aynı formatta vermez; bazıları saniye, bazıları saat damgası döner.
- Sitenizin kodu bu başlığı okuyup akıllıca bekleme yapacak şekilde yazılmamışsa, istek hemen tekrar gönderilir ve döngü içinde aynı hata tekrar tekrar alınır — bu da tedarikçi tarafında sizi geçici olarak bloke ettirebilir.
Yani 429 tek seferlik bir uyarı değil, sistemin "trafiği düzenli hale getir" diye verdiği bir sinyaldir. Bu sinyali görmezden gelen entegrasyonlar zamanla tedarikçi tarafında güven kaybına, hatta hesabın geçici olarak kısıtlanmasına kadar gidebilir.
Manuel entegrasyonlarda rate limit neden felakete dönüşür?
Kendi yazdığınız veya bir yazılımcıya ısmarlama yazdırdığınız bir entegrasyonda genellikle "mutlu senaryo" test edilir: tek sipariş, tek istek, sorunsuz yanıt. Rate limit senaryosu ise ancak yoğun günde, canlı ortamda ortaya çıkar — ve o an zaten en çok satış yapmanız gereken andır. Tipik sonuçlar şöyle olur:
- Sipariş oluşturulur, ödeme alınır ama kod isteği rate limit'e takılır — müşteri parasını ödemiş, elinde ürün yok.
- Kod isteği "başarısız" görünüp aslında tedarikçi tarafında işlenmiş olabilir — mükerrer sipariş riski doğar, aynı ürün iki kez düşer.
- Panel "hata" gösterir ama arka planda ne olduğu belirsizdir; destek ekibi manuel olarak tedarikçi paneline girip kontrol etmek zorunda kalır.
- Stok senkronu bozulur çünkü fiyat/stok sorgulama istekleri de aynı limite dahildir ve site yanlış stok bilgisi göstermeye başlar.
Bu senaryoların ortak noktası şudur: sorun teknik olarak küçük (bir HTTP kodu) ama sonucu büyüktür (kayıp para, kızgın müşteri, itibar zedelenmesi). Kampanya döneminde manuel entegrasyonların çöktüğü şikayetleri çoğunlukla tam olarak bu nedene dayanır.
| Durum | Manuel / Elle | Pinova ile |
|---|---|---|
| 429 hatası alındığında | İstek hemen tekrar gönderilir, döngü oluşur | Otomatik bekleme + kademeli yeniden deneme (backoff) |
| Yoğun kampanya trafiği | Siparişler sıraya girmeden aynı anda gönderilir | Dahili kuyruk isteği tedarikçi hızına göre sıralar |
| Ödeme alındı ama kod gelmedi | Destek ekibi elle tedarikçi panelinden kontrol eder | Sistem otomatik yeniden dener, başarısızsa iade/bakiye tetiklenir |
| Çoklu tedarikçi (Turkpin+Pinabi) | Her biri ayrı limit, ayrı takip gerekir | Tedarikçi bazında ayrı kuyruk ve limit takibi otomatik |
| Mükerrer sipariş riski | Yüksek — hangi isteğin işlendiği belirsiz | İdempotency kontrolü ile aynı sipariş iki kez işlenmez |
Kuyruk ve backoff stratejisi nedir, nasıl kurulur?
Rate limit sorununu çözmenin yolu tedarikçiye daha hızlı istek atmak değil, isteklerinizi düzenli bir sıraya sokmaktır. Bunun için iki temel mekanizma birlikte çalışır:
- Kuyruk (queue): Gelen siparişler anında tedarikçiye gönderilmez, önce bir sıraya alınır. Sistem, tedarikçinin izin verdiği hızda (örneğin saniyede 2 istek) bu sırayı işler. Trafik ne kadar yoğun olursa olsun, tedarikçiye giden istek akışı sabit ve öngörülebilir kalır.
- Kademeli yeniden deneme (exponential backoff): Bir istek 429 hatası alırsa hemen tekrar denenmez; 1 saniye, sonra 2 saniye, sonra 4 saniye gibi artan aralıklarla tekrar denenir. Bu, hem tedarikçinin sınırına saygı gösterir hem de geçici yoğunluk geçtiğinde isteğin başarıyla tamamlanma ihtimalini artırır.
Bu iki mekanizma birlikte kurulmadığında biri diğerini boşa çıkarır: sadece kuyruk varsa ama backoff yoksa, kuyruktaki her istek yine art arda hata alıp birikir. Sadece backoff varsa ama kuyruk yoksa, yoğun anda binlerce istek aynı anda "bekleme" moduna girip sunucu kaynağını tüketir. İkisi birlikte, düzenli ve dayanıklı bir akış oluşturur.
Kampanya günlerinden önce tedarikçinizin dokümantasyonundaki rate limit değerini not edin ve sitenizin kuyruk hızını bu değerin biraz altına ayarlayın. "Sınırın tam üstünde" çalışmak, küçük bir trafik dalgalanmasında bile hata almanıza yeterli olur.
Birden çok tedarikçi kullanırken sırayı kim yönetecek?
Çoğu e-pin sitesi tek bir tedarikçiyle sınırlı kalmaz; Turkpin'den bir ürün, Pinabi'den başka bir ürün çekilir, bazı ürünler için ikinci bir yedek tedarikçi tanımlanır. Bu durumda rate limit yönetimi tek bir sayı değil, tedarikçi başına ayrı bir sınırdır — ve karıştırılırsa sorun büyür:
- Turkpin'in limiti dolduğunda Pinabi isteklerinin de etkilenmemesi gerekir; ayrı kuyruklar şart.
- Bir tedarikçi geçici olarak yanıt vermiyorsa (rate limit veya bakım), sistemin bunu fark edip o ürünü "geçici olarak müsait değil" göstermesi, aksi halde satılan ürünün teslim edilememesi anlamına gelir.
- Yedek tedarikçi tanımlıysa ve birincisi limite takılırsa, siparişin otomatik olarak ikinciye yönlendirilmesi müşteri deneyimini kesintisiz tutar.
Bunu elle takip etmek, özellikle 5-6 tedarikçiyle çalışan bir siteyi işletirken pratik olarak imkânsız hale gelir; her tedarikçinin ayrı bir panelde ayrı bir "durum"u takip edilmesi gerekir.
Pinova bu sorunu arka planda nasıl çözüyor?
Pinova'nın tedarikçi API entegrasyonu (Turkpin/Pinabi) tam olarak yukarıda anlatılan kuyruk + backoff mantığıyla çalışır ve bunu site sahibinin hiç görmesine gerek kalmadan yapar. Sipariş geldiğinde önce dahili kuyruğa alınır, tedarikçiye tanımlı hız sınırına göre işlenir; 429 gibi bir yanıt gelirse otomatik olarak kademeli bekleme devreye girer ve istek arka planda tekrar denenir. Bu sırada:
- Müşteri parası site cüzdanında güvende tutulur, sipariş "işleniyor" durumunda gösterilir.
- Aynı sipariş birden fazla kez tedarikçiye gönderilmez (idempotency kontrolü) — mükerrer düşme riski ortadan kalkar.
- Belirlenen deneme sayısı sonunda hâlâ başarısız olan siparişler otomatik olarak bakiyeye iade edilir veya admin panelinde işaretlenir, elle takip gerekmez.
- Çok seviyeli bayi sistemi ve stok senkronu da aynı kuyruk mantığından geçtiği için, kampanya yoğunluğunda bayi siparişleri de aynı disiplinle işlenir.
Sonuç olarak site sahibi için görünen tek şey, kampanya gecesi sistemin çökmemesi ve destek kutusunun "param nerede" mesajlarıyla dolmamasıdır — arka planda dönen kuyruk ve yeniden deneme mekanizması sessizce işini yapar.
Sıradaki sipariş de mi kuyrukta kalacak?
Pinova ile tedarikçi API'niz kaç isteğe izin veriyorsa, sitenizin trafiği o hıza otomatik uyum sağlar — siz kampanya yapmaya devam edersiniz.
Rate limit hatası müşteriye nasıl görünür?
Doğru yönetilmiş bir sistemde müşteri rate limit'i hiç görmez; sipariş "işleniyor" olarak kalır ve arka planda birkaç saniye içinde tamamlanır. Kötü yönetilen bir entegrasyonda ise müşteri doğrudan hata sayfasıyla karşılaşır ya da ödemesi alınıp kod gelmez.
Turkpin ve Pinabi'nin rate limit değerleri farklı mı?
Evet, her tedarikçi kendi altyapısına göre farklı bir sınır belirler ve bu değerler zaman içinde değişebilir. Bu yüzden sabit bir kuyruk hızı yerine tedarikçi bazında ayrı ayrı yönetim gerekir.
Kendi yazdığım entegrasyona sonradan kuyruk sistemi eklenebilir mi?
Teknik olarak mümkündür ama mevcut sipariş akışını, ödeme mantığını ve bakiye sistemini bozmadan eklemek ciddi bir yeniden yapılandırma gerektirir; çoğu zaman sıfırdan kurmaktan daha zahmetli olur.
Pinova'da rate limit ayarlarını ben mi yapıyorum?
Hayır, kuyruk ve yeniden deneme mantığı sistemin çekirdeğinde hazır gelir; siz sadece tedarikçi API bilgilerinizi panelden tanımlarsınız, gerisini sistem yönetir.