Çoğu e-pin satıcısı tedarikçi entegrasyonunu tek adımlık bir iş sanır: anahtarı al, endpoint'i panele yaz, ilk siparişi test et, kapat. Doküman sayfasındaki örnek istek çalıştığı anda entegrasyonun bittiğine inanılır. Oysa entegrasyonun gerçek sınavı ilk istekte değil, kampanya gecesinin 23.40'ında, aynı dakika içinde onlarca siparişin düştüğü, panelin arka planda hem stok senkronizasyonu hem bakiye sorgusu hem de sipariş gönderimi yaptığı anda başlar. O anda tedarikçinin sana verdiği istek hakkı dolar ve API cevap vermeyi bırakır.
İşin tuhaf tarafı şu: o gece yaşanan şey bir arıza değildir. Tedarikçi tam da yazdığı gibi davranır, senin e-pin scriptin ise bu davranışa hazırlıklı değildir. Kullandığın dijital ürün satış scripti istek sayacını takip etmiyorsa, 429 cevabını kuyruğa almıyorsa ve tek bir anahtarla bütün trafiği aynı borudan geçiriyorsa, ölçeklendiğin anda kendi kendini boğar. Bu yazıda rate limit mantığını, kota bütçelemeyi ve anahtar yönetimini bir işletme sahibinin gözünden, panel tarafında ne kurulması gerektiğine kadar açıyoruz.
Tedarikçi Sana Kaç İstek Hakkı Verdiğini Neden Net Söylemiyor?
Tedarikçi dokümanlarının büyük kısmında rate limit ya hiç yazmaz ya da "aşırı istek göndermeyiniz" gibi ölçülemez bir cümleyle geçiştirilir. Bunun sebebi kötü niyet değil, tavanın çoğu zaman bayi bazında ve dinamik olarak belirlenmesidir. Aynı sağlayıcı sana dakikada 60, yanındaki büyük bayiye 300 istek hakkı tanımış olabilir. Bazı sistemlerde tavan endpoint bazındadır: stok listesi dakikada 10, sipariş oluşturma dakikada 120.
Bu belirsizliği kabul etmek yerine ölçmen gerekir. Panelin her giden isteğini zaman damgasıyla loglaması ve hangi endpoint'te hangi saniyede hata aldığını kaydetmesi, sana dokümanın söylemediği gerçek tavanı iki hafta içinde verir. Ölçmediğin bir sınırı yönetemezsin; tahminle kurulan entegrasyon her kampanyada yeniden kırılır.
429 Hatası Bir Arıza Değil, Tedarikçinin Sana Attığı Fren mi?
HTTP 429 cevabı "sistemim bozuldu" demez, "yavaşla" der. Doğru kurulmuş bir e-pin satış yazılımı bu cevabı hata olarak müşteriye yansıtmaz; isteği kuyruğa alır, bekler ve tekrar dener. Kritik nokta beklemenin nasıl yapıldığıdır. Sabit aralıklı tekrar denemeler, aynı anda frene çarpan tüm isteklerin aynı saniyede tekrar hücum etmesine yol açar; buna sürü etkisi denir ve tavanı ikinci kez kırar.
Çözüm üstel geri çekilmedir: 1 saniye, 2 saniye, 4 saniye, 8 saniye şeklinde artan bekleme sürelerine küçük bir rastgele sapma eklenir. Böylece kuyruktaki istekler zamanda yayılır. Ayrıca tedarikçi Retry-After başlığı gönderiyorsa kendi hesabını bırakıp o değere uymalısın. Panelin bu davranışı merkezi bir istemci katmanında yapması, her entegrasyon dosyasında ayrı ayrı yazılmasından çok daha sağlamdır.
| Strateji | Nasıl çalışır | Kota koruması | Uygun olduğu durum |
|---|---|---|---|
| Sabit tekrar deneme | Her hatada 2 sn bekleyip yeniden dener | Zayıf | Tek kullanıcılı test ortamı |
| Üstel geri çekilme | Bekleme süresi katlanarak artar | Yüksek | Sipariş gönderimi, bakiye sorgusu |
| Token bucket | Dakikalık jeton bütçesi tüketilir | Çok yüksek | Yoğun kampanya trafiği |
| Önbellekli okuma | Stok/fiyat verisi 60-300 sn saklanır | Çok yüksek | Ürün listesi, kur bilgisi |
| Toplu (batch) istek | Tek çağrıda çok ürün sorgulanır | Yüksek | Gece senkronizasyonu |
Tek Anahtarla Çalışmak Neden Zamanla Kendini Kilitliyor?
Birçok satıcı tedarikçiden aldığı tek anahtarı hem canlı sipariş hem stok senkronizasyonu hem de test için kullanır. Bu, üç ayrı trafiğin aynı kotayı paylaşması demektir. Gece çalışan senkronizasyon görevi kotanın yarısını yerse, gündüz gelen sipariş isteği duvara çarpar. Daha kötüsü: test sırasında yaptığın bir hata canlı satışı durdurur.
Doğru yaklaşım anahtarı role göre ayırmaktır. Tedarikçin çoklu anahtar veriyorsa okuma, yazma ve test için ayrı anahtarlar tanımla. Vermiyorsa bile panel içinde mantıksal ayrım kurabilirsin: senkronizasyon işleri düşük öncelikli kuyruğa, sipariş işleri yüksek öncelikli kuyruğa gider ve düşük öncelikli kuyruk kota tükenmeye yakınken otomatik duraklatılır. Bu tek karar, kampanya gecelerinde satış kaybının büyük kısmını önler.
Panelde Kota Tüketiminin Dağılımı
- Stok ve fiyat sorguları 45%
- Sipariş oluşturma 25%
- Bakiye ve durum kontrolü 20%
- Test ve manuel çağrılar 10%
Anahtarını Nerede Tuttuğunu Gerçekten Biliyor musun?
Rate limit teknik bir konu, anahtar güvenliği ise doğrudan para konusudur. Tedarikçi anahtarı sızan bir satıcının bakiyesi saatler içinde boşaltılabilir. Sahadaki en yaygın üç hata şunlar: anahtarın sürüm kontrolüne (git) işlenmesi, veritabanında düz metin saklanması ve panel arayüzünde tam haliyle görüntülenmesi.
Sağlam bir epin yazılım kurgusunda anahtar ortam dosyasında ya da webroot dışındaki bir konumda durur, veritabanına yazılacaksa şifrelenmiş biçimde yazılır ve arayüzde yalnızca son dört karakteri gösterilir. Yetki tarafında da aynı disiplin geçerlidir: kimlerin entegrasyon ayarlarına girebildiği rol bazlı sınırlanmalı, her görüntüleme ve değiştirme işlemi denetim kaydına düşmelidir. Anahtarın kim tarafından ne zaman değiştirildiğini bilmiyorsan, bir sızıntı yaşandığında nereden başlayacağını da bilemezsin.
Tedarikçi tavanının tamamını kullanmak yerine panelde yüzde 70 iç tavan tanımla. Kalan yüzde 30, iade, yeniden deneme ve manuel müdahale gibi öngörülemeyen çağrılar için güvenlik payıdır.
Kota Duvarına Çarpmadan Önce Hangi Metrikleri İzlemelisin?
Entegrasyonu "çalışıyor mu, çalışmıyor mu" ikilisine indirgemek en pahalı alışkanlıktır. İzlemen gereken dört metrik var: dakikalık istek sayısı, 429 ve 5xx oranı, ortalama yanıt süresi ve kuyrukta bekleyen iş sayısı. Bu dördü bir arada okunduğunda sorunun tedarikçide mi, senin panelinde mi yoksa trafik yoğunluğunda mı olduğu anlaşılır.
Uyarı eşikleri de otomatik olmalı. Dakikalık istek sayısı iç tavanın yüzde 80'ine ulaştığında panel senkronizasyon sıklığını kendiliğinden düşürebilir; 429 oranı yüzde 5'i geçtiğinde sana bildirim gitmelidir. Böyle bir e-pin satış scripti sorunu sen fark etmeden önce yönetmiş olur. Müşterinin "sipariş gelmedi" mesajı bir izleme aracı değildir.
Anahtar Rotasyonunu Neden Herkes Erteliyor?
Rotasyon erteleniyor çünkü çoğu panelde anahtarı değiştirmek kesinti demek. Eski anahtar siliniyor, yeni anahtar yazılıyor ve arada kalan istekler hata veriyor. Bu yüzden satıcılar aynı anahtarı yıllarca kullanıyor; oysa ekip değişikliği, bayi paneli paylaşımı ve eski yedeklerin dolaşımı düşünüldüğünde bu ciddi bir risktir.
Kesintisiz rotasyonun yolu çift anahtar penceresidir: yeni anahtar tanımlanır, panel bir süre her iki anahtarı da geçerli kabul eder, yeni anahtarla başarılı istek oranı yüzde yüze ulaştığında eski anahtar devre dışı bırakılır. Bu yapıyı destekleyen bir dijital ürün satış yazılımı ile rotasyon on beş dakikalık rutin bir işe dönüşür. Pinova'nın entegrasyon katmanı tam olarak bu mantıkla tasarlandı: merkezi istemci, rol bazlı anahtar saklama, kota sayacı ve kuyruk önceliği tek yerden yönetilir. Ayrıntıları özellikler bölümünde, paket farklarını ise fiyat sayfasında görebilirsin.
| Kontrol | Neden gerekli | Sıklık | Durum |
|---|---|---|---|
| Giden istek logu açık mı | Gerçek tavanı ölçmenin tek yolu | Sürekli | Zorunlu |
| Üstel geri çekilme kurulu mu | 429 sonrası sürü etkisini engeller | Sürekli | Zorunlu |
| İç kota tavanı tanımlı mı | Tedarikçi tavanına çarpmayı önler | Aylık gözden geçirme | Zorunlu |
| Okuma/yazma anahtarı ayrı mı | Senkronizasyon satışı bloklamaz | Kurulumda | Önerilir |
| Anahtar şifreli saklanıyor mu | Veritabanı sızıntısında zararı sınırlar | Kurulumda | Zorunlu |
| Rotasyon takvimi var mı | Eski anahtarın dolaşım riskini kapatır | 90 gün | Önerilir |
| 429 oranı alarmı kurulu mu | Müşteriden önce sen haberdar olursun | Sürekli | Önerilir |
Entegrasyon katmanını tahminle değil ölçümle yönet
Kota sayacı, kuyruk önceliği ve şifreli anahtar yönetimi hazır gelen bir panelle kampanya gecelerini sorunsuz geçir.
Tedarikçim rate limit değerini paylaşmıyor, ne yapmalıyım?
Giden istek logunu açıp iki hafta boyunca dakikalık istek sayısı ile 429 cevaplarını eşleştir. Hatanın başladığı eşik senin pratik tavanındır; iç limitini bunun yüzde 70'ine sabitle.
Önbellek kullanmak stok hatası riskini artırır mı?
Doğru sürelerle hayır. Ürün listesi ve fiyat gibi yavaş değişen veriler 60-300 saniye önbelleklenebilir; kritik kontrol olan sipariş anındaki stok doğrulaması her zaman canlı yapılmalıdır.
Anahtarı veritabanında tutmak güvenli mi?
Düz metin olarak tutmak güvenli değildir. Şifrelenmiş saklama, arayüzde maskeleme, rol bazlı erişim ve denetim kaydı birlikte uygulandığında veritabanı kabul edilebilir bir konum olur.
Kesinti yaşamadan anahtar değiştirebilir miyim?
Evet. Panelin iki anahtarı geçici olarak birlikte kabul ettiği bir geçiş penceresi tanımlarsan, yeni anahtar doğrulandıktan sonra eskisini kapatabilir ve hiç hata üretmezsin.
Kota yönetimi ve anahtar disiplini, dışarıdan görünmeyen ama ciro tablosunu doğrudan belirleyen bir altyapı meselesidir. Panelinin bu işleri senin yerine yapıp yapmadığını en hızlı şekilde denemekle anlarsın: canlı demo üzerinden entegrasyon ekranlarını aç, kota sayacını ve anahtar maskelemesini kendi gözünle gör, sonra mevcut sistemindeki karşılığını yanına koy. Farkı bir kampanya gecesine bırakmadan görmek her zaman daha ucuzdur.