Rate Limiting

Apa itu Rate Limiting?

Rate limiting adalah teknik untuk mengontrol jumlah permintaan yang dapat dilakukan klien ke API dalam jangka waktu tertentu. Tujuannya melindungi backend dari abuse, menjaga ketersediaan layanan, dan memastikan distribusi resource yang adil antar pengguna.

Algoritma Rate Limiting

Token Bucket

Bucket berisi token yang terisi secara periodik (misal 10 token per detik). Setiap permintaan mengonsumsi satu token. Jika bucket kosong, permintaan ditolak (429 Too Many Requests). Kelebihan: mengakomodasi burst traffic (token bisa dikumpulkan hingga kapasitas bucket maksimum). Cocok untuk API dengan pola traffic yang melonjak.

Leaky Bucket

Permintaan masuk ke buffer (bucket) dengan kapasitas tetap, lalu diproses dengan kecepatan konstan (leak rate). Jika buffer penuh, permintaan ditolak. Berbeda dengan Token Bucket yang mengizinkan burst, Leaky Bucket memaksa traffic rate yang seragam. Cocok untuk stabilisasi traffic ke downstream yang sensitif terhadap lonjakan.

Fixed Window

Permintaan dihitung dalam jendela waktu tetap (misal 100 requests per menit). Setiap jendela dimulai ulang setelah interval tertentu. Kelemahan: rentan terhadap traffic spike di batas jendela - klien dapat mengirim 100 request di detik terakhir jendela A dan 100 request di detik pertama jendela B (200 request dalam 2 detik). Sederhana diimplementasikan tetapi kurang akurat.

Sliding Window

Memperbaiki kelemahan Fixed Window dengan menggunakan jendela geser. Implementasi umum: Sliding Window Log (mencatat timestamp setiap request) atau Sliding Window Counter (gabungan counter jendela saat ini dan residual jendela sebelumnya). Lebih akurat dan mulus dalam membatasi rate. Standar di Redis-based rate limiter modern.

Implementasi

Per IP

Membatasi berdasarkan alamat IP klien. Paling sederhana, tetapi mudah di-bypass via IP rotation atau botnet. Rentan false positive jika banyak pengguna legitimate di belakang satu NAT (kantor, sekolah).

Per User

Membatasi berdasarkan user ID (setelah autentikasi). Lebih akurat daripada per IP karena mengikuti identitas pengguna, bukan alamat jaringan. Cocok untuk API yang memerlukan login. Butuh token valid di setiap request.

Per Endpoint

Kombinasi dari IP/user dengan endpoint spesifik. Contoh: endpoint /login dibatasi 5 request per menit per IP (mencegah brute-force), sementara endpoint /search dibatasi 100 request per menit per user. Fleksibel dan memungkinkan granular control.

Headers Rate Limiting

Standar de facto untuk menginformasikan status rate limiting ke klien:

• X-RateLimit-Limit: Batas maksimum request dalam window (misal 100).
• X-RateLimit-Remaining: Sisa request yang tersedia di window saat ini.
• X-RateLimit-Reset: Timestamp Unix kapan window akan di-reset.

Beberapa API juga menyertakan Retry-After header saat rate limit terlampaui (HTTP 429).

Tools & Implementasi

NGINX limit_req Module

Modul bawaan NGINX menggunakan algoritma Leaky Bucket. Dikonfigurasi via limit_req_zone (definisi zone) dan limit_req (lokasi). Contoh:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ { limit_req zone=api burst=20; }

Kong

Plugin rate limiting bawaan dengan dukungan Redis untuk distributed rate limiting. Mendukung second, minute, hour, day, month. Bisa dikonfigurasi per consumer, per credential, atau per IP.

Redis

Backend paling populer untuk rate limiting. Algoritma umum: Fixed Window (INCR + EXPIRE), Sliding Window (ZREMRANGEBYSCORE + ZCARD pada sorted set). Redis Sentinel/Cluster memungkinkan rate limiting terdistribusi di lingkungan multi-instance.

Cloudflare

Rate limiting di edge network sebelum traffic mencapai origin server. Mendukung berbagai level (per IP, per ASN, per country) dan action (block, challenge, JS challenge, log). Efektif untuk mitigasi DDoS layer 7.

Bypass Techniques

• IP Rotation: Menggunakan proxy, VPN, atau botnet untuk menghindari limit per IP. Mitigasi: user-based rate limiting dan behavioral analytics.
• Distributed Attack: Setiap IP mengirim request di bawah threshold. Mitigasi: aggregate monitoring + anomaly detection.
• Timing Attack: Request dikirim sangat lambat melewati window. Mitigasi: sliding window algorithm.
• Header Spoofing: Memanipulasi header (X-Forwarded-For). Mitigasi: validasi trusted proxy chain.

API Abuse Prevention

Selain rate limiting, kombinasi strategi berikut dianjurkan:

1. Rate limiting berlapis - per IP + per user + per endpoint.
2. Adaptive rate limiting - menyesuaikan threshold berdasarkan pola traffic dan reputasi klien.
3. CAPTCHA/challenge - untuk endpoint sensitif (login, registration).
4. Usage quotas - batas harian/bulanan untuk API keys.
5. Monitoring & alerting - deteksi anomali rate secara real-time.
6. Throttling response - alih-alih menolak, perlambat response (HTTP 429 + Retry-After).