Rate limit, sistemi koruyan bir mekanizmadır; düşman değildir. Doğru kullanılırsa hem entegrasyonunuz daha güvenilir olur hem de Buaze tarafında genel performans korunur.
Yüksek 429 oranı bir performans sorunu değil, bir tasarım sorunudur. Limite tepki kodlamak yerine limitle uyumlu yazmak baştan kolaydır.
Tipik limitler
Çoğu endpoint dakika başına orta seviye bir istek tavanına sahiptir. AI Co-Pilot gibi maliyetli endpoint’lerde tavan daha düşüktür ve workspace owner seviyesinde keylenir, böylece bir ekip üyesi quota’yı tek başına tüketemez.
Sağlıklı istek deseni
- Ardışık istekler arasında 100-300 ms boşluk.
- Toplu görevleri 50’şerli batch’lere bölün.
- Cache kullanın: aynı veriyi 5 dakikada tekrar istemeyin.
- Backoff: 429 alındığında 2-4-8 sn beklemeyle retry.
- Retry sayacı 3’ü geçmesin, sonra alarm yakın.
Operasyonel izleme
Entegrasyon tarafında 429 oranını dashboard’a yazın. Yüksek orana ulaşırsa bu, performans sorunu değil tasarım sorunudur ve istek mimarisi gözden geçirilmelidir.
Kontrol listesi / Checklist
- 429 oranı dashboardda izleniyor.
- Backoff stratejisi kodlandı.
- Toplu işlem batch boyutu belirlendi.
- Cache TTL set edildi.
- Alarm 3+ retry sonrası tetikleniyor.
SSS / FAQ
429 alırsam veri kaybolur mu?
Hayır. Doğru kurulmuş retry mekanizması isteği yeniden gönderir. Veri kaybı tasarım hatasıdır, limitin kendisi sebep değildir.
Limit yükseltilebilir mi?
Belirli iş senaryoları için destek ekibiyle değerlendirilebilir. Önce mevcut deseni optimize etmek önerilir.