Rate Limit: Memahami Batasan Kuota API

Kenapa API dibatasi?

Server punya sumber daya terbatas. Tanpa batasan, satu client yang bug (atau jahat) bisa membanjiri server dengan ribuan request per detik sampai tumbang. Karena itu hampir semua API menerapkan rate limit: jumlah maksimum request dalam jangka waktu tertentu, misalnya 100 request per jam per API key.

Membaca info kuota dari header

API yang rapi memberi tahu sisa kuotamu lewat header respons:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1728307200

Artinya: batas 100 request, sisa 87, kuota di-reset pada timestamp tersebut. Tidak semua API memakai nama header yang sama, jadi selalu cek dokumentasinya. Kalau kuota habis, server membalas:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Status 429 artinya "kebanyakan request, coba lagi nanti", dan header Retry-After: 60 memintamu menunggu 60 detik.

Strategi frontend yang bijak

Kena 429 bukan akhir dunia kalau kodemu siap. Polanya:

async function fetchBijak(url) {
  const res = await fetch(url);

  if (res.status === 429) {
    const tunggu = Number(res.headers.get("Retry-After") || "60");
    console.log("Kena rate limit, tunggu " + tunggu + " detik...");
    await new Promise((r) => setTimeout(r, tunggu * 1000));
    return fetchBijak(url); // coba lagi setelah menunggu
  }

  if (!res.ok) throw new Error("Error: " + res.status);
  return res.json();
}

Tapi strategi terbaik adalah tidak kena limit sama sekali:

• Cache respons yang jarang berubah. Data profil user tidak perlu di-request tiap render.
• Debounce input pencarian: tunggu user berhenti mengetik 300ms sebelum mengirim request, bukan tiap keystroke.
• Gabungkan request kalau API menyediakan endpoint batch.

Satu pola polling setInterval yang memanggil API tiap detik adalah cara tercepat menghabiskan kuota. Kalau butuh data realtime, tanyakan ke backend apakah ada WebSocket atau webhook.

Rate limit saat development

Saat ngoprek, kamu mungkin kena 429 padahal merasa "baru sedikit request". Penyebab umum: limit dihitung per IP atau per API key, dan di jaringan kantor/kampus satu IP dipakai banyak orang. Solusinya: pakai API key pribadi (banyak API memberi kuota per key, bukan per IP), kecilkan frekuensi polling saat debug, dan manfaatkan data mock lokal untuk iterasi cepat. Jangan meminta backend menaikkan limit global cuma karena kamu sedang development, itu mengorbankan proteksi untuk semua orang.

Catatan teknis: Selalu hormati header Retry-After. Melakukan retry agresif tepat setelah kena 429 justru memperpanjang masa hukumanmu di banyak implementasi, karena tiap request yang ditolak ikut dihitung. Mundur, tunggu sesuai instruksi, lalu coba lagi dengan tenang. Kalau aplikasimu butuh kuota lebih besar secara permanen, itu urusan upgrade plan API, bukan trik di kode.