AI API’lerinde 410 Gone ve 429 Too Many Requests Hataları

Bir AI entegrasyonu haftalardır sorunsuz çalışırken aynı gün iki farklı hata üretmeye başladı. Bir çağrıda model artık mevcut olmadığı için 410, diğerinde yoğun istek nedeniyle 429 dönüyordu. İlk refleks her iki hatayı da kısa süre bekleyip yeniden denemekti. Bu yaklaşım 429 için bile dikkatli uygulanmalı; 410 içinse aynı isteği tekrarlamak yalnızca gecikme ve gereksiz trafik üretir.

20 Temmuz 2026 tarihli incelemede HTTP durum kodunu kullanıcıya gösterilecek mesajdan ayırıp uygulama davranışını hata sınıfına göre tasarladık. Model yaşam döngüsü, oran sınırı, kota, sağlayıcı geçişi ve güvenli kayıt birlikte ele alındı. Amaç hatayı gizlemek değil; işlemin güvenli biçimde sürdürülmesi veya açıkça durdurulması için öngörülebilir bir yol oluşturmaktı.

Sorunun ortaya çıkışı

Uygulamada model adı yapılandırmaya sabit yazılmıştı. Sağlayıcı modelin kullanım ömrünü tamamladığında API 410 Gone döndürdü ve bütün kullanıcılar aynı anda etkilendi. Başka bir iş akışında eş zamanlı belge özetleri kısa sürede istek sınırını doldurdu. 429 cevapları arttıkça istemciler hemen yeniden denedi ve yoğunluğu daha da büyüten bir tekrar fırtınası oluştu.

İki olay dışarıdan “AI cevap vermiyor” şeklinde görünüyordu, fakat müdahale biçimleri farklıydı. 410 yapılandırma ve yaşam döngüsü olayıydı; model kataloğunun güncellenmesi ve uyumluluk testi gerekiyordu. 429 kapasite ile akış kontrolü olayıydı; bekleme başlığı, kota penceresi, eş zamanlılık ve istek maliyeti analiz edilmeliydi. Tek genel hata yakalayıcı bu ayrımı görünmez yapmıştı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım her 4xx yanıtın kullanıcı girdisinden kaynaklandığıydı. 410 servis sağlayıcının kaynak yaşam döngüsü kararını gösterebilir; 429 ise dakika başına istek, token, eş zamanlılık veya toplam kota sınırlarından biri olabilir. Yalnızca durum koduna bakıp hangi limitin aşıldığını anlamak mümkün değildir. Yanıt başlıkları, sağlayıcı hata gövdesi ve gözlem metrikleri birlikte değerlendirilmelidir.

İkinci varsayım fallback modelin kesintisiz ve eşdeğer sonuç vereceğiydi. Alternatif model farklı context sınırı, araç çağırma biçimi, güvenlik politikası, fiyatlandırma veya çıktı kalitesi taşıyabilir. Kullanıcıdan habersiz geçiş özellikle yapılandırılmış çıktı ve otomasyonda hataya yol açar. Fallback ancak uyumluluğu önceden test edilmiş görevlerde, sürüm ve sonuç görünürlüğü korunarak kullanılmalıdır.

Teknik analiz

Hata sınıflandırmasını kalıcı, geçici ve istemci kaynaklı olarak ayırdık. 410 kalıcı kabul edilerek devre kesici açıldı, sorumlu ekibe model ve uç nokta bilgisiyle alarm üretildi. 429 geçici sınıfta ele alındı; Retry-After varsa bu süreye uyuldu, yoksa üst sınırı ve rastgele sapması olan exponential backoff kullanıldı. Sonsuz deneme yerine görev türüne göre azami deneme ve zaman bütçesi belirlendi.

İstek, token, gecikme ve 429 oranları model ile iş akışı bazında izlendi. Toplu işler kuyruğa alınarak etkileşimli kullanıcılardan ayrıldı. Büyük istemler bölündü veya gereksiz bağlam azaltıldı. Model kataloğunda aktif, kullanımdan kalkacak ve kapalı durumları ile son destek tarihi tutuldu. Böylece sağlayıcı duyuruları üretim hatasına dönüşmeden önce test ve geçiş işi açılabildi.

// Güvenli örnek: sınırlı deneme, Retry-After ve rastgele sapma.
async function callWithBackoff(call, maxAttempts = 4) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const response = await call();
    if (response.status === 410) throw new Error('MODEL_RETIRED');
    if (response.status !== 429) return response;

    const retryAfter = Number(response.headers.get('retry-after'));
    const waitMs = Number.isFinite(retryAfter)
      ? retryAfter * 1000
      : Math.min(1000 * 2 ** attempt + Math.random() * 250, 10000);
    await new Promise(resolve => setTimeout(resolve, waitMs));
  }
  throw new Error('RATE_LIMIT_RETRY_EXHAUSTED');
}

Uygulanan çözüm veya önerilen mimari

Uygulama ile sağlayıcı arasına ince bir model yönlendirme katmanı koyduk. İş akışları doğrudan değişken sağlayıcı adlarına değil, “hızlı özet” veya “yapılandırılmış analiz” gibi onaylı profil adlarına bağlandı. Her profil için birincil model, test edilmiş alternatif, context sınırı ve özellik gereksinimi tanımlandı. 410 alındığında profil devre dışı kalıyor, uygun fallback yoksa işlem anlaşılır mesajla duruyordu.

429 yönetiminde merkezi oran sınırlayıcı, öncelikli kuyruk ve eş zamanlılık sınırı kullanıldı. Etkileşimli çağrılar ile zamanlanmış toplu işler ayrı havuzlara alındı. Kullanıcıya ham sağlayıcı hatası yerine talebin sıraya alındığı veya daha sonra denenmesi gerektiği söylendi. Operasyon ekranında başarısızlık oranı, tüketim eğilimi, kuyruk yaşı ve model yaşam döngüsü alarmı birlikte izlendi.

Alternatifler ve karar gerekçesi

Her hatada başka modele geçmek erişilebilirliği artırabilir, ancak çıktı tutarlılığı ve maliyet kontrolünü zayıflatır. Hiç fallback kullanmamak davranışı öngörülebilir tutar fakat uygun işlerde gereksiz kesinti yaratır. Bu nedenle düşük riskli, test edilmiş iş akışlarında otomatik; kritik veya yapılandırılmış sonuçlarda kullanıcı onaylı ya da kontrollü geçiş tercih edildi. Model değişikliği her zaman telemetride görünür kaldı.

Kota artırmak 429 sıklığını azaltabilir, fakat kötü eş zamanlılık tasarımını ve gereksiz token kullanımını çözmez. Yalnızca istemci backoff’u da çok sayıda uygulama örneğinde yeterli olmayabilir. Merkezi kuyruk ile uygulama tarafı backoff’un birlikte kullanılması yükü dengeler. Birden fazla sağlayıcı seçeneği dayanıklılık sunar; veri işleme koşulları ve özellik uyumluluğu doğrulanmadan otomatik yönlendirme yapılmamalıdır.

Güvenlik ve operasyonel riskler

Hata ayıklama sırasında istemlerin tamamını, erişim anahtarlarını veya kullanıcı belgelerini loglamak ciddi veri riski yaratır. Kayıtlar korelasyon kimliği, durum kodu, model profili, süre ve güvenli hata sınıfıyla sınırlandırılmalıdır. Fallback sağlayıcısına geçiş veriyi farklı hukuki veya coğrafi koşullara taşıyabileceği için yalnızca önceden onaylanmış hedefler kullanılmalı, hassas veri sınıfları ayrı politika ile yönetilmelidir.

Kontrolsüz yeniden deneme maliyet artışı, çift işlem ve hizmet çökmesine yol açabilir. Devre kesici, toplam süre bütçesi, kuyruk sınırı ve iptal desteği bu nedenle önemlidir. Modelin emekliye ayrılması yalnızca teknik hata değil değişiklik yönetimi olayıdır; prompt, çıktı şeması ve güvenlik davranışı yeni modelde regresyon testinden geçmelidir. Sağlayıcı durum sayfası tek gözlem kaynağı olmamalıdır.

Çıkarılan Dersler

Kontrol Listesi