HTTP 429 Too Many Requests: Retry-After dan percobaan ulang yang aman

Temukan komponen yang mengirim 429

Catat waktu, endpoint, metode, status, ID permintaan, dan header yang berkaitan dengan pengulangan. Jangan masukkan kredensial atau data pribadi ke log. Pastikan respons berasal dari API tujuan, proksi balik, atau aturan CDN. Tampilan halaman kesalahan saja tidak menjelaskan kuota yang berlaku.

Batas dapat berlaku untuk alamat IP, pengguna terautentikasi, aplikasi, atau sumber daya. Isi respons dan dasbor penyedia mungkin menunjukkan kuota yang habis. Batas per menit, batas permintaan aktif, dan kuota harian memerlukan penanganan berbeda. Memperlambat antrean tidak mengisi ulang kuota harian yang sudah habis.

• Apakah beban naik karena pekerjaan baru atau karena satu pekerjaan terus mengulang?
• Apakah beberapa layanan, tab, atau kunci API berbagi kuota akun?
• Apakah yang dibatasi jumlah permintaan, permintaan aktif, token, atau sumber daya lain?
• Apakah waktu pemulihannya masih sesuai dengan tenggat tindakan pengguna?

Baca satuan Retry-After dengan benar

Retry-After dapat berisi bilangan bulat tak negatif dalam detik atau tanggal HTTP. Nilai 12 berarti menunggu dua belas detik setelah respons diterima, bukan milidetik. Untuk tanggal, hitung interval yang tersisa memakai jam yang andal. Tanggal yang sudah lewat tidak membenarkan perulangan rapat tanpa batas.

Gunakan jeda server yang sah sebagai waktu minimum. Tambahkan penyebaran acak kecil bila banyak pekerja akan berjalan lagi bersama. Jika jeda melebihi waktu pekerjaan yang tersisa, hentikan atau jadwalkan ulang; jangan diam-diam memendekkannya lalu menghubungi layanan terlalu cepat.

Anggarkan antrean gabungan dan permintaan aktif

Misalkan satu akun mendapat 120 permintaan per menit dan pekerjaan berisi 600 permintaan. Tanpa aktivitas lain pun dibutuhkan beberapa menit jatah. Mengirim semua sekaligus lalu tidur sampai akhir menit tetap menghasilkan lonjakan yang bisa ditolak walaupun rata-ratanya tampak sesuai.

Pilih target operasi 90 per menit agar ada ruang untuk pekerjaan lain. Itu sama dengan 1.5 permintaan per detik atau jarak sekitar 667 milidetik. Sebanyak 600 permintaan memerlukan sekitar 400 detik sebelum tambahan waktu respons dan pengulangan. Perhitungan ini membantu perencanaan, bukan jaminan cocok dengan setiap jenis jendela pembatasan.

Dengan respons rata-rata dua detik, Hukum Little memberikan sekitar 1.5 × 2 = 3 permintaan aktif pada keadaan stabil. Semaphore membatasi operasi yang berlangsung, sedangkan pembatas laju bersama mengatur waktu mulai. Keduanya dibutuhkan sesuai masalahnya; percobaan ulang juga memakai anggaran yang sama.

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

Batasi backoff dan tambahkan jitter

Jika tidak tersedia jeda server yang dapat dipakai, naikkan jendela tunggu setelah kegagalan berulang dan pilih jeda acak di dalamnya. Jendela satu, dua, empat, lalu delapan detik membantu menyebarkan percobaan. Tetapkan tenggat total secara terpisah agar pekerjaan tidak menunggu selamanya.

Fungsi berikut hanya menghitung jeda. Fungsi ini bukan klien pengulangan lengkap dan tidak mengirim permintaan. Pemanggil wajib mengendalikan tenggat, batas percobaan, pembatalan, dan keamanan operasi. Di peramban, server mungkin perlu mengekspos Retry-After melalui CORS agar JavaScript dapat membacanya.

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

Ulangi hanya bila akibatnya sudah dipahami

Membaca data berbeda dengan membuat pembayaran. Sebelum mengulang penulisan, periksa aturan idempotensi dan kemungkinan percobaan sebelumnya sudah berhasil. Jika didukung, gunakan kunci idempotensi yang sama untuk operasi logis yang sama. Kunci baru setiap kali dapat menciptakan operasi terpisah.

SDK mungkin sudah mengulang secara internal. Pembungkus pengulangan tambahan bisa melipatgandakan lalu lintas. Catat batas total percobaan jaringan di semua lapisan. Untuk pengguna, tampilkan keadaan coba lagi nanti yang jelas daripada menyembunyikan antrean panjang di balik tombol yang terus berputar.

• Tetapkan satu tenggat pekerjaan dan teruskan pembatalan ke antrean.
• Batasi jumlah permintaan aktif serta laju mulai pada kuota gabungan.
• Lepaskan sumber daya respons sebelum menunggu atau mencoba lagi.
• Berhenti pada kuota habis atau kesalahan yang dinyatakan permanen.
• Catat percobaan dan hasil akhirnya agar pengulangan terlihat dalam pemantauan.

Uji perbaikan dengan kelompok kecil terkontrol

Mulailah dari sejumlah pembacaan yang dapat dihitung. Pisahkan percobaan awal, pengulangan, keberhasilan, dan kegagalan akhir. Cocokkan jarak waktu serta jumlah operasi aktif dengan rencana. Setelah itu simulasikan 429 dengan Retry-After yang diketahui tanpa berulang kali membebani layanan produksi.

Kalkulator laju permintaan membantu mengubah satuan detik dan menit, sedangkan kalkulator konkurensi memeriksa asumsi latensi. Bandingkan rencana dengan kuota sebenarnya. Jika 429 tetap muncul, telusuri pemanggil lain dan jenis batas sebelum sekadar menambah jeda.