Apa Itu Rate Limiting? Panduan Bahasa Sederhana untuk App Builder

Rate limiting adalah aturan yang membatasi berapa banyak permintaan yang bisa dibuat seseorang ke sebuah sistem dalam jangka waktu tertentu — misalnya 5 percobaan login per menit, atau 100 panggilan API per jam. Setelah batas tercapai, permintaan selanjutnya ditolak (biasanya dengan kode error 429 Too Many Requests) sampai jendela waktunya ter-reset. Ini melindungi aplikasi dari penyalahgunaan, mencegah satu pengguna berat memperlambat semua orang, dan menghentikan biaya yang membengkak tanpa kendali.

Anda bertemu rate limiting dari dua sisi: layanan yang Anda panggil membatasi Anda, dan aplikasi Anda sendiri sebaiknya membatasi penggunanya.

Mengapa rate limiting penting saat membangun dengan AI

Aplikasi yang dibangun dengan AI sering terhubung ke layanan berbayar — model AI, email, SMS, peta — dan setiap panggilan memakan biaya. Itu membuat rate limiting sekaligus fitur keamanan dan fitur anggaran.

• Kontrol biaya. Jika aplikasi Anda punya kotak "tanya AI" tanpa batas, bot bisa mengirim ribuan permintaan semalaman. Anda membayar setiap permintaan itu.
• Keamanan. Tanpa batas pada formulir login, penyerang bisa mencoba ribuan kata sandi ke sebuah akun. Batas beberapa percobaan per menit membuat itu tidak praktis.
• Tetap online. Satu skrip yang bermasalah — kadang kode Anda sendiri yang terjebak dalam loop — bisa membebani basis data dan membuat aplikasi mati.
• Menghormati batas layanan lain. Ketika aplikasi Anda memanggil API luar terlalu sering, Anda yang mendapat error 429, dan fitur untuk pengguna Anda ikut rusak.

AI builder akan membangun apa yang Anda minta. Jika Anda tidak menyebutkan batas, sering kali hal itu terlewat.

Analogi sehari-hari

Bayangkan kebijakan isi ulang gratis di sebuah kedai kopi: "Satu isi ulang gratis per pelanggan per kunjungan."

• Itu tidak menghalangi siapa pun untuk menikmati kopi.
• Itu mencegah satu orang berdiri di meja kasir sepanjang hari mengisi ulang termos untuk seluruh kantor.
• Saat seseorang meminta isi ulang keempat, barista dengan sopan berkata "belum bisa sekarang" — itulah 429-nya.

Rate limit yang baik tidak terlihat oleh pelanggan biasa dan hanya terasa oleh orang yang melakukan sesuatu yang tidak wajar.

Cara kerja rate limiting

Rate limiter memerlukan tiga hal:

Saat permintaan datang, aplikasi memeriksa jumlah untuk "siapa" tersebut. Di bawah batas: permintaan diteruskan dan jumlahnya naik. Di atas batas: permintaan ditolak.

Ada beberapa cara umum untuk menghitung:

Hitungannya perlu disimpan di tempat yang cepat dan bisa dibagi. Di satu server kecil, memori sudah cukup. Begitu aplikasi berjalan di beberapa mesin, penghitung biasanya berada di penyimpanan bersama seperti Redis atau basis data; jika tidak, tiap mesin menghitung sendiri-sendiri dan batas yang sebenarnya menjadi beberapa kali lebih tinggi.

Seperti apa respons yang melebihi batas

Saat permintaan melebihi batas, API yang baik merespons dengan:

• Kode status 429 Too Many Requests.
• Sering kali header Retry-After, yang menyebutkan berapa detik harus menunggu.
• Kadang header yang menunjukkan batas Anda dan berapa permintaan yang tersisa dalam jendela ini (nama-namanya berbeda antar penyedia).

Aplikasi Anda sebaiknya merespons 429 dengan menunggu dan mencoba lagi nanti — idealnya dengan exponential backoff, yaitu menunggu sedikit lebih lama setelah setiap percobaan yang gagal (1 detik, lalu 2, lalu 4), alih-alih terus-menerus menghantam layanan.

Contoh nyata: asisten penulisan AI

Anggap Anda membangun aplikasi tempat pengguna menempelkan teks dan mendapat hasil tulis ulang dari AI.

Tanpa batas: seseorang menulis skrip yang mengirim 20.000 permintaan semalaman. Tagihan penyedia AI Anda melonjak, dan akun Anda mencapai batas rate limit penyedia itu sendiri, sehingga pengguna sungguhan melihat error sepanjang pagi.

Dengan batas yang masuk akal:

1. Per pengguna yang sudah masuk: 30 tulis ulang per jam untuk paket gratis, 300 untuk paket berbayar. Jika melebihi batas, pengguna melihat: "Anda sudah mencapai batas jam ini. Coba lagi dalam 12 menit, atau upgrade."
2. Per alamat IP pada formulir pendaftaran: 5 pendaftaran per jam, untuk mencegah bot membuat ribuan akun gratis guna menghindari batas per pengguna.
3. Batas pengeluaran yang diatur di dasbor penyedia AI Anda, sebagai lapisan pertahanan terakhir jika semua yang lain gagal.
4. Menangani batas penyedia: jika penyedia AI mengembalikan 429, server Anda menunggu dan mencoba lagi satu atau dua kali, lalu menampilkan pesan ramah "sedang sibuk, silakan coba lagi".

Batas diperiksa di server. Batas yang hanya ada di browser — misalnya menonaktifkan tombol setelah 30 klik — bisa dilewati siapa pun yang memanggil API Anda secara langsung.

Istilah kunci

Kesalahpahaman umum

• "Rate limiting hanya untuk aplikasi besar." Aplikasi kecil juga menjadi sasaran, karena bot memindai seluruh internet untuk mencari formulir dan endpoint AI yang terbuka. Biaya penyalahgunaan tidak bergantung pada ukuran Anda.
• "Menyembunyikan tombol sudah cukup." Batas di sisi browser hanya bentuk kesopanan, bukan perlindungan. Batas yang sebenarnya harus ditegakkan di server.
• "Batas per IP selalu adil." Banyak orang bisa berbagi satu alamat IP — kantor, sekolah, jaringan seluler. Batas per pengguna lebih adil begitu orang sudah masuk.
• "Error 429 berarti layanannya rusak." Artinya Anda memanggilnya terlalu sering. Periksa kode Anda untuk loop, dan simpan (cache) hasil yang jarang berubah — lihat apa itu caching.
• "Rate limiting menggantikan batas pengeluaran." Gunakan keduanya. Batas di aplikasi Anda bisa punya bug; batas pengeluaran penyedia adalah cadangan Anda.

Yang bisa Anda tanyakan ke AI builder Anda

• "Tambahkan rate limiting di sisi server untuk login, pendaftaran, reset kata sandi, dan endpoint AI. Sarankan batas yang masuk akal."
• "Batasi setiap pengguna yang sudah masuk hingga [N] permintaan AI per jam, dan tampilkan pesan yang jelas dengan waktu tunggu saat batas tercapai."
• "Saat API luar mengembalikan 429, coba lagi dengan exponential backoff hingga 3 kali, lalu tampilkan error yang ramah."
• "Di mana penghitung rate limit disimpan? Apakah tetap berfungsi jika aplikasi berjalan di lebih dari satu mesin?"
• "Catat setiap kali pengguna atau IP mencapai batas, agar saya bisa mengenali penyalahgunaan."
• "Layanan luar mana saja yang dipanggil aplikasi ini, dan berapa batas rate limit mereka?"

Rate limiting di Mythex

Dokumentasi Mythex lugas soal ini untuk fitur AI: rate limit, keamanan, dan kontrol biaya di aplikasi yang Anda bangun adalah tanggung jawab Anda untuk dirancang — lihat Membangun aplikasi AI. Mintalah agen menambahkan batas dalam pesan yang sama ketika Anda meminta fitur tersebut. Di Pro, layanan yang dipublikasikan bisa berjalan di hingga tiga mesin saat lalu lintas tinggi (lihat Batas hosting), jadi mintalah penghitung yang disimpan di basis data, bukan di memori satu server.

Bacaan terkait: apa itu API, cara memakai LLM API, dan daftar periksa keamanan untuk aplikasi buatan AI.

Pertanyaan