Ringkasan Masalah Diagnosa Rate Limit Anthropic

Worker backend yang memanggil API Anthropic terus menerus mengalami retry dan timeout, walaupun antrean job tidak menggelembung di awal. Masalahnya bukan sekadar network jitter, melainkan pola retry yang mengabaikan header rate limit dan memicu cascade failure pada satu job panjang.

Dalam 1-2 paragraf ini: root cause awal sudah jelas. Worker harus planten kembali diagnosis rate limit, memperbaiki retry policy, dan menambahkan monitoring agar gejala tidak kembali.

Gejala dan Observasi

Log awal menunjukkan retry meledak

Worker menulis log seperti berikut:

[2024-10-01T10:12:01Z] job=compile-document status=error msg="Anthropic request failed" code=429
[2024-10-01T10:12:01Z] job=compile-document retry=1 wait=100ms
[2024-10-01T10:12:01Z] job=compile-document retry=2 wait=200ms
... hingga retry ke-30

Artinya, job masih melakukan retry walau API menolak karena rate limit. Retry count terus meningkat, mengunci worker, dan job lainnya tertunda sehingga antrean akan bertambah.

Observability alat mengungkap header yang diabaikan

Pantauan distribusi latency menunjukkan banyak respon 429 dengan header x-ratelimit-reset dan x-ratelimit-requests. Bahkan ada indikasi worker tidak menunggu sama sekali sebelum mencoba kembali. Log tambahan dari middleware HTTP memperlihatkan bahwa aplikasi membuang header-header tersebut sebelum retry policy dieksekusi.

Analisis Kasus

Retry explosion akibat backoff yang salah urut

Penyebab pertama adalah misordered backoff. Implementasi awal membangun array backoff seperti [100ms, 50ms, 150ms] dan selalu mengambil entry berdasarkan min(retryCount, length-1), sehingga penambahan retry bisa menetap pada 50ms walau seharusnya naik. Karena periode penungguannya sangat pendek, worker menabrak rate limit terus-menerus.

Header rate-limit tidak digunakan

Worker mengabaikan header X-Ratelimit-Delay dan X-Ratelimit-Reset yang disediakan Anthropic. Saat 429 terjadi, middleware harus menyimpan informasi itu dan memberi tahu retry policy agar menunggu sampai reset selesai. Tanpa info ini, worker tidak bisa fail fast atau backoff secara adaptive.

Perbaikan Praktis

Koreksi retry policy dan backoff

Susun ulang mekanisme retry agar selalu menaik sesuai eksponensial atau secara konfigurasi. Terapkan ulang logika agar backoff diurutkan naik dan digabungkan dengan header rate limit.

const fixedBackoff = [100, 250, 500, 1000, 2000];
function getDelay(retryCount, headers) {
  const fromHeader = Number(headers['x-ratelimit-reset']) || null;
  if (fromHeader) {
    const reset = Math.max(0, fromHeader - Date.now());
    return Math.max(reset, fixedBackoff[Math.min(retryCount, fixedBackoff.length - 1)]);
  }
  return fixedBackoff[Math.min(retryCount, fixedBackoff.length - 1)];
}

Dengan cara ini, worker menunggu minimal 100ms untuk retry pertama, 2 detik di retry terakhir, dan bisa menunda lebih lama jika header menyarankan reset.

Tambahkan circuit breaker dan fail fast

Ketika satu job terus-menerus mendapatkan 429, sebaiknya worker memutus sekitar job tersebut dan memindahkan intent ke retry queue terpisah setelah threshold tercapai. Circuit breaker dapat diimplementasikan dengan counter 429 per job atau per worker, misalnya:

if (consecutive429 >= 5) {
  publishToHighLatencyQueue(job);
  throw new Error('Circuit open: skip further Anthropic retries for now.');
}

Fail fast menghindari timeout panjang di antrean utama dan memberi operator waktu untuk meninjau penyebab rate limit.

Monitoring rate limit rate dan log observability

Gunakan dashboard seperti Grafana untuk menampilkan metrik:

  • Jumlah 429 per interval dan per worker.
  • Rata-rata backoff yang dipilih untuk tiap job.
  • Retry queue depth setelah circuit breaker trip.

Pastikan sistem mengirim event ketika header x-ratelimit-reset diterima dengan nilai tinggi sehingga tim bisa melakukan scaling request ke Anthropic.

Mitigasi Jangka Panjang untuk Pipeline Job Sejenis

1. Queue Adaptation: Pisahkan job berat (menghasilkan banyak request) ke worker pool berbeda dengan rate limit yang lebih konservatif.

2. Token Bucket dari sisi client: Terapkan rate limiter internal agar jumlah request rata-rata tidak melebihi kuota (misal 50 request per 30 detik).

3. Retry Policy Contract: Dokumentasikan bagaimana job menanggapi 429, kapan circuit breaker dipicu, dan bagaimana operator men-debug 429 yang konsisten.

4. Fallback ringan: Jika Anthropic tidak tersedia, worker bisa meredirect job ke mode degrade dengan pesan “request ditolak karena rate limit” tanpa memblokir antrean lain.

Kesimpulan

Diagnosa Rate Limit Anthropic di worker backend memerlukan kombinasi observasi log, koreksi retry/backoff, dan proteksi seperti circuit breaker. Saat gejala seperti retry explosion muncul, arahkan diagnosis ke header rate limit dan kebijakan backoff agar sistem bisa fail fast dan menyelamatkan pipeline lain. Tambahkan monitoring serta mitigasi jangka panjang agar kejadian serupa bisa diantisipasi.