Integrasi yang berjalan mulus saat diuji dengan belasan permintaan mulai menerima penolakan ketika beban nyata datang. Penyebabnya bukan kerusakan pada API, melainkan laju permintaan yang melampaui ambang batas yang diizinkan. Kita bahas mengapa batas semacam ini ada, cara membedakannya dari gangguan layanan, cara meratakan beban di sisi Anda, dan mengapa memeriksa status setiap detik biasanya tidak mempercepat hasil.
Mengapa layanan membatasi frekuensi permintaan
Batas melindungi infrastruktur bersama: tanpa pembatasan, satu klien dengan skrip agresif dapat menghabiskan sumber daya yang dibutuhkan semua pengguna lain. Batas ini juga membagi kapasitas secara adil, karena ambang per akun menjamin integrasi pihak lain tidak menghabiskan bandwidth yang sudah Anda bayar. Saat Anda menyentuh batas itu, tandanya jelas: layanan membalas dengan kode 429 dan sering menyertakan header berisi jeda yang disarankan sebelum mencoba lagi. Ini sangat berbeda dari gangguan layanan, karena saat terjadi gangguan, semua klien menerima error pada berbagai operasi, sedangkan throttling ditujukan khusus ke kunci Anda dan disebabkan oleh laju permintaan kunci tersebut. Jika respons berisi kode pembatasan yang jelas, berarti infrastruktur masih hidup dan bekerja normal. Masalahnya ada pada kecepatan Anda mengirim permintaan, bukan pada layanannya.
Laju yang merata, bukan lonjakan
Banyak batas dihitung per jendela waktu, yaitu per detik atau per menit. Jika Anda mengirim seratus permintaan sekaligus lalu diam, penghitung jendela langsung habis, padahal beban rata-rata per jam mungkin kecil. Pembatasan bereaksi terhadap puncak, bukan rata-rata. Jumlah pekerjaan yang sama, bila disebar merata di dalam jendela, lolos tanpa satu pun penolakan. Meratakan laju bukan berarti mengurangi jumlah permintaan, melainkan tidak memadatkannya dalam rentang waktu yang sempit.
Antrean dan pembatasan alur paralel di sisi Anda
Tugas dalam aplikasi jarang muncul secara merata: satu gelombang pekerjaan bisa datang sekaligus, misalnya setelah impor data atau operasi massal oleh pengguna. Jika setiap tugas langsung memicu permintaan ke API, lonjakan di sisi Anda berubah menjadi lonjakan di perbatasan layanan. Antrean dengan kecepatan keluar yang terkontrol mengatasi ketidaksinkronan ini: tugas menumpuk di antrean, sementara permintaan yang keluar mengalir dengan stabil. Selain itu, batasi juga jumlah koneksi paralel ke API. Sekalipun sudah ada antrean, sepuluh alur yang menembak endpoint dengan batas frekuensi secara bersamaan menciptakan lonjakan yang sama seperti satu alur tanpa pengendalian.
Polling status dan jeda saat ditolak
Memeriksa status operasi setiap detik hampir selalu berlebihan: hasil tidak muncul lebih cepat hanya karena Anda menanyakannya lebih sering. Operasi nyata, seperti pengiriman SMS, pembuatan port, atau pemrosesan pembayaran, dibatasi oleh jaringan dan antrean internal layanan itu sendiri. Polling yang lebih sering dari waktu alaminya hanya menghabiskan kuota tanpa mendekatkan jawaban. Interval polling yang wajar ditentukan dari waktu eksekusi operasi yang lazim, bukan dari keinginan melihat hasil seketika.
Setelah ditolak karena batas, jangan langsung mengulang permintaan dengan laju yang sama, sebab itu pasti memperpanjang pemblokiran. Reaksi yang tepat adalah jeda eksponensial: setiap percobaan berikutnya menunggu lebih lama dari sebelumnya, misalnya satu detik, lalu dua, empat, dan delapan. Jika layanan mengembalikan header dengan waktu tunggu yang disarankan, ikuti waktu itu, bukan perkiraan Anda sendiri.
Batas terpisah per kunci dan pemantauan ambang
Batas hampir selalu terikat pada kunci atau akun, bukan pada layanan secara keseluruhan. Jika sinkronisasi latar belakang dan skenario pengguna memakai kunci API yang sama, tugas latar belakang yang berat dapat menghabiskan seluruh kuota dan membuat pengguna biasa tidak mendapat respons. Kunci berbeda untuk tugas berbeda menghasilkan penghitung berbeda, dengan prinsip pemisahan yang sama seperti pada API proxy. Selain itu, pantau pemakaian kuota secara proaktif: banyak API mengembalikan sisa kuota dalam responsnya, dan dari angka itu di dasbor akun terlihat bahwa Anda mendekati ambang sebelum penolakan terjadi, bukan setelah 429 pertama.
Pertanyaan yang Sering Diajukan
Apakah batas untuk akun tertentu bisa dinaikkan?
Pada sebagian layanan, batas naik seiring paket langganan atau lewat permintaan khusus ke dukungan dengan menjelaskan skenario beban Anda. Jangan mengandalkannya dari awal. Lebih tepat merancang integrasi sesuai ambang saat ini, dan menganggap kenaikan batas sebagai bonus, bukan rencana.
Mengapa 429 muncul padahal laju permintaan kecil?
Penyebab yang sering adalah kunci yang dipakai bersama proses lain yang sudah menghabiskan sebagian kuota. Penyebab kedua adalah jendela batas yang lebih pendek dari perkiraan: laju rata-rata per menit rendah, tetapi di dalam satu detik terjadi lonjakan. Periksa kedua kemungkinan ini sebelum mengubah logika integrasi itu sendiri.
Apakah batasnya sama untuk semua metode API?
Biasanya tidak: operasi berat seperti pencarian atau pengambilan data massal dibatasi lebih ketat daripada pemeriksaan status sederhana. Acuan yang tepat adalah tabel batas per metode di dokumentasi, bukan satu angka umum.
Nilai batas yang pasti, kode error, dan header jeda sebelum mencoba lagi tersedia di dokumentasi OTP API.