Rate Limiting API: Cara Membatasi Permintaan Tanpa Merusak Pengalaman Pengguna

API yang terbuka tanpa pembatasan dapat kewalahan oleh kesalahan klien, bot, atau penyalahgunaan yang disengaja. Rate limiting membatasi jumlah permintaan yang boleh dilakukan dalam periode tertentu. Tujuannya bukan hanya mencegah serangan, tetapi juga menjaga layanan tetap responsif dan memberi kesempatan yang adil bagi pengguna lain.

Rate limiting bukan sekadar memblokir IP

Batas dapat diterapkan berdasarkan alamat IP, akun, API key, organisasi, endpoint, atau kombinasi beberapa identitas. Membatasi IP saja sering tidak cukup: banyak pengguna sah dapat berbagi satu alamat melalui NAT, sedangkan pelaku bisa berganti alamat. Untuk API terautentikasi, batas per pengguna atau tenant biasanya lebih bermakna, sementara pembatasan IP menjadi lapisan tambahan.

Pilih algoritma sesuai kebutuhan

• Fixed window: menghitung permintaan dalam jendela waktu tetap. Mudah dibuat, tetapi lonjakan di batas dua jendela dapat menggandakan trafik sesaat.
• Sliding window: menghitung permintaan pada jendela yang bergerak atau memperkirakannya dari dua jendela. Polanya lebih halus, dengan biaya implementasi lebih tinggi.
• Token bucket: mengisi kembali token dari waktu ke waktu dan mengizinkan lonjakan kecil selama token tersedia. Cocok untuk API yang perlu fleksibel.
• Leaky bucket: mengatur keluaran agar lebih stabil dan dapat membantu meratakan lonjakan.

Tidak ada algoritma terbaik untuk semua kasus. Endpoint pencarian, pengiriman email, login, dan ekspor laporan memiliki biaya serta risiko berbeda. Karena itu, batas sebaiknya ditetapkan per kelas operasi, bukan dengan satu angka untuk seluruh API.

Rancang respons yang bisa ditangani klien

Jika batas terlampaui, HTTP 429 Too Many Requests adalah respons yang lazim. Sertakan informasi yang membantu klien mengetahui kapan boleh mencoba lagi, misalnya header Retry-After bila sesuai. Dokumentasi harus menjelaskan batas, cara menangani respons, dan apakah batas dihitung per akun atau endpoint. Rujukan protokolnya dapat dibaca di RFC 6585.

Klien sebaiknya menerapkan exponential backoff dengan jitter agar banyak proses tidak mengulang permintaan bersamaan. Hindari retry tanpa batas: mekanisme seperti itu dapat memperparah gangguan ketika server sedang kelebihan beban.

Langkah implementasi yang praktis

1. Ukur pola trafik normal dan biaya komputasi tiap endpoint.
2. Tentukan identitas pembatas yang sesuai: akun, tenant, API key, IP, atau gabungan.
3. Pisahkan batas untuk operasi murah dan operasi mahal.
4. Simpan penghitung di komponen yang konsisten ketika aplikasi berjalan di banyak server.
5. Berikan respons 429 yang jelas dan dokumentasikan perilaku retry.
6. Catat jumlah penolakan, latensi, dan penggunaan kapasitas tanpa menyimpan data sensitif yang tidak perlu.
7. Uji pengguna sah yang berbagi IP, pekerjaan batch, dan lonjakan trafik yang realistis.

Kesalahan yang sering terjadi

Batas yang terlalu ketat bisa memutus integrasi sah, sedangkan batas terlalu longgar tidak melindungi sumber daya. Menggunakan penyimpanan penghitung lokal pada setiap server juga dapat membuat batas efektif berlipat ganda. Jangan menjadikan rate limiting sebagai pengganti autentikasi, validasi input, atau pembatasan biaya bisnis.

Untuk endpoint login, gabungkan rate limiting dengan deteksi penyalahgunaan dan proses pemulihan akun yang aman. Untuk endpoint mahal, pertimbangkan kuota harian, antrean pekerjaan, dan batas ukuran permintaan.

Kesimpulan

Rate limiting yang baik menggabungkan batas yang terukur, algoritma yang sesuai, respons yang dapat dipahami klien, serta pemantauan yang berkelanjutan. Mulailah dari endpoint berisiko tinggi, uji dampaknya pada pengguna nyata, lalu sesuaikan kebijakan berdasarkan data. Pelajari pula praktik keamanan API dan HTTP security headers untuk membangun pertahanan berlapis.