Forge çağrı limiti yükseldi: Saniyelik tavan yeni darboğaz olabilir

Atlassian, 1 Eylül 2026 tarihli Forge değişiklik kaydında kullanıcı kaynaklı çağrılar için kurulum başına sınırı 5.000 RPM’den, 300 RPS veya 7.000 RPM’den hangisi önce dolarsa ona değiştirdiğini duyurdu. Kapsam, Forge uygulamalarının kullanıcı arayüzünden ve web tetikleyicilerinden başlatılan çağrıları içeriyor; kullanıcı başına 1.200 RPM sınırı korunurken ortam başına 30.000 RPM tavanı kaldırılıyor.

Dakikalık kapasite yüzde 40 yükseliyor, fakat Jira veya Confluence üzerinde kısa sürede yoğun çağrı oluşturan bir uygulama 7.000 RPM’ye ulaşmadan 300 RPS sınırına çarpabilir. Üstelik güncel referans belgesinin hâlâ 5.000 RPM göstermesi, duyurulan değer ile yayımlanmış teknik tablo arasında giderilmesi gereken bir uyumsuzluk bulunduğu anlamına geliyor.

Duyurulan ve belgelenen sınırlar aynı değil

Değişiklik kaydındaki yeni model ile teknik referansın mevcut tablosu birlikte okunduğunda iki farklı kurulum sınırı görülüyor. Bağımsız bir teknik değerlendirme de değişiklikten önce geçerli yapıyı kullanıcı başına 1.200 RPM, kurulum başına 5.000 RPM ve ortam başına 30.000 RPM olarak sıralıyor; ayrıca Forge çağrı sınırlarının aktif biçimde değiştirildiği uyarısını yapıyor. Bu önceki değerler ClonePartner’ın 2026 mimari karşılaştırmasında yer alıyor.

• Önceki model: Kullanıcı başına 1.200 RPM, kurulum başına 5.000 RPM ve ortam başına 30.000 RPM.
• 1 Eylül duyurusu: Kullanıcı başına 1.200 RPM; kurulum başına 300 RPS veya 7.000 RPM’den önce dolan eşik; ortam düzeyindeki 30.000 RPM sınırının kaldırılması.
• Güncel referans tablosu: Kurulum başına 300 RPS veya 5.000 RPM’den önce dolan eşik.

Bu fark, yalnızca belge düzenine ilişkin bir ayrıntı değil. Bir ekip kapasite hesabını 7.000 RPM üzerinden yaparken çalışan ortamda 5.000 RPM uygulanıyorsa, kurulum beklenenden 2.000 çağrı önce sınırlanabilir. Değişiklik kaydındaki “güncelleniyor” ifadesi de ayrı bir tamamlanma tarihi veya bütün kurulumları kapsayan dağıtım onayı vermiyor.

300 RPS hangi durumda önce dolar?

Dakikalık ve saniyelik eşikler farklı trafik biçimlerini sınırlar. 7.000 çağrı bir dakikaya eşit dağıtıldığında ortalama hız yaklaşık 116,7 RPS olur; bu düzenli yükte dakikalık kota önce dolar. Aynı çağrılar birkaç kısa kullanıcı dalgasında toplanırsa, toplam dakika hacmi düşük görünürken tek bir saniye 300 çağrıyı aşabilir.

Koşullu bir örnekte, aynı Forge kurulumu bir saniye içinde 350 kullanıcı kaynaklı çağrı alırsa ilk 300 çağrı saniyelik kapasiteyi doldurur. Dakikanın geri kalanında çok az trafik bulunsa bile aşan bölüm için 429 yanıtları oluşabilir. Bu nedenle 7.000 RPM artışı, ani Jira toplu işlemlerinde veya çok sayıda Confluence kullanıcısının aynı anda bir uygulama bileşenini çalıştırdığı durumda 7.000 çağrının tamamının kullanılabileceği anlamına gelmez.

Sabit 120 RPS üreten başka bir koşullu yük dakikada 7.200 çağrıya ulaşır. Saniyelik tavanı aşmaz, ancak 7.000 RPM kotasını yaklaşık 58,3 saniyede doldurur. Sabit 100 RPS ise dakikada 6.000 çağrı üretir: yeni duyurudaki değerin altında kalırken referans tablosundaki 5.000 RPM uygulanıyorsa yaklaşık 50 saniye sonra sınırlanır.

Kullanıcı ve kurulum sayaçları da birbirinin yerine geçmez. Tek bir kullanıcı 1.200 RPM’ye ulaştığında kurulum toplamı düşük olsa bile çağrıları sınırlanabilir; çok sayıda kullanıcının eşzamanlı faaliyeti ise kişi başına kota dolmadan kurulum toplamını veya 300 RPS tavanını tüketebilir.

429 yanıtı sıfırlama zamanına göre yönetilmeli

Forge’un güncel invocation limits belgesi, kullanıcı kaynaklı çağrılarda sabit bir dakikalık pencere uygulandığını; kurulum sınırını 5.000 RPM ve 300 RPS’den önce dolan eşik olarak gösteriyor. Aynı belge, ön uç çağrılarında istek yükünü 500 KB, yanıt yükünü 5 MB ile sınırlıyor ve 429 alan çağrının açık pencere sıfırlanmadan yeniden gönderilmemesini istiyor.

Kullanıcı arayüzünden yapılan invoke çağrılarında geri deneme zamanı, istenen rateLimitProperties metadatasındaki rateLimitReset alanından alınabiliyor. Web tetikleyicilerinde karşılık gelen değer 429 yanıtının X-RateLimit-Reset başlığında bulunuyor. Her iki akışta da amaç, aynı çağrıyı hemen tekrarlayıp henüz kapanmamış sınırlama penceresine yeniden çarpmamak.

1. Yanıtın 429 olduğunu doğrula; başka hata türlerini aynı geri deneme akışına sokma.
2. UI çağrısında rateLimitReset, web tetikleyicisinde X-RateLimit-Reset değerini oku.
3. Belirtilen sıfırlama zamanına kadar yeni denemeyi beklet.
4. Çağrıyı önceden belirlenmiş sınırlı sayıda yeniden dene.
5. Sıfırlama değeri yoksa veya geçersizse sınırsız döngü yerine hatayı kaydet ve denemeyi durdur.

Bu akış, sınırın kendisini yükseltmez; yalnızca aşım anında yeni çağrıların mevcut yükü büyütmesini engeller. Ani trafiği azaltmak için çağrıların zamana yayılması, kullanıcı eylemlerinin tek bir saniyede aynı kurulum üzerinde yığılmasını önleyen ayrı bir kapasite kararıdır.

Yürürlük durumu belgelerin eşitlenmesini bekliyor

3 Eylül 2026 itibarıyla değişiklik kaydı 7.000 RPM ve 300 RPS modelini duyuruyor, teknik referans ise 5.000 RPM ve 300 RPS değerlerini birlikte göstermeyi sürdürüyor. Bağımsız teknik yayın, değişiklik öncesindeki 5.000 RPM tabanını ve sınır modelinin geçiş halinde olduğunu doğruluyor; ancak 1 Eylül güncellemesinin bütün Forge ortamlarında tamamlandığına ilişkin bağımsız bir uygulama ölçümü sunmuyor.

Kesin olan nokta, 300 RPS eşiğinin hem duyuruda hem güncel referansta bulunması ve kısa trafik patlamalarının dakikalık kotadan bağımsız biçimde 429 üretebilmesi. 7.000 RPM’nin tüm kurulumlardaki fiilî durumu için Atlassian’ın referans tablosunu duyuruyla eşitlemesi veya dağıtım durumunu ayrıca netleştirmesi gerekiyor.

Ayrıca okuyun:

• a16z’den yapay zekâ altyapısına 1,1 milyar dolarlık yeni fon