Strategi Rate Limiting Dan Throttling: Melindungi Infrastructure API Dari Traffic Surge Dan DDoS

Mengapa Rate Limiting Adalah Pilar Keamanan Utama

Dalam lanskap aplikasi web dan microservices terdistribusi, API merupakan antarmuka utama yang menghubungkan pengguna, aplikasi seluler, dan sistem pihak ketiga dengan basis data backend. Tanpa adanya kontrol kuota permintaan yang ketat, satu pengirim permintaan yang berniat jahat atau sebuah skrip yang megalami bug eksekusi berulang (infinite loop) dapat dengan mudah menghabiskan seluruh resource CPU, memori, dan pool koneksi basis data.

Implementasi rate limiting dan throttling bukan hanya berfungsi sebagai benteng pertahanan dari serangan Distributed Denial of Service (DDoS) dan credential stuffing, melainkan juga menjaga prinsip keadilan alokasi resource (fair usage policy) bagi seluruh pengguna sah.

"Rate limiting adalah rem darurat utama infrastruktur API. Sistem backend yang hebat bukan hanya mampu memproses jutaan request dengan cepat, melainkan juga mampu menolak request berbahaya sebelum menyentuh lapisan aplikasi utama."

MAYASTRA NAWALOKA, API Security Infrastructure Architect

Evaluasi Algoritma Rate Limiting

Terdapat empat algoritma fundamental yang umum digunakan untuk mengendalikan laju permintaan HTTP ke backend API:

• Token Bucket: Menambahkan token ke dalam ember (bucket) dengan laju tetap. Setiap request mengambil satu token. Jika ember kosong, request ditolak. Sangat fleksibel untuk menangani lonjakan singkat (traffic burst).
• Leaky Bucket: Memproses request dengan laju konstan mirip air yang menetes keluar dari ember yang bocor. Memperhalus lonjakan lalu lintas menjadi laju yang sangat stabil.
• Fixed Window Counter: Menghitung jumlah request di dalam jendela waktu tetap (misalnya 100 request per 1 menit). Rentan terhadap lonjakan batas jendela (boundary burst) hingga 2x lipat kuota.
• Sliding Window Counter: Menggabungkan hitungan dari jendela waktu sebelumnya dan jendela berjalan secara proporsional. Memberikan akurasi tertinggi tanpa kelemahan lonjakan batas.

Matriks Komparasi Algoritma Rate Limiting

Tabel berikut menyajikan evaluasi komparatif antara keempat algoritma rate limiting untuk arsitektur API skala tinggi:

Implementasi Production-Grade dengan Redis & Lua Script

Pada arsitektur backend terdistribusi yang terdiri dari banyak instance server atau API Gateway, pencatatan hitungan rate limit harus dilakukan secara terpusat dan atomic di dalam storage in-memory seperti Redis. Menggunakan Lua script menjamin bahwa pemeriksaan dan pembaruan counter berlangsung secara atomis tanpa mengalami kondisi racikan (race condition).

-- Redis Lua Script untuk Sliding Window Counter
-- KEYS[1]: Key unik client (misal: ratelimit:ip:192.168.1.1 atau ratelimit:user:usr_8912)
-- ARGV[1]: Timestamp saat ini dalam milidetik
-- ARGV[2]: Jendela waktu (window size) dalam milidetik (misal: 60000 ms)
-- ARGV[3]: Batas maksimum request dalam jendela waktu (misal: 100)

local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local limit = tonumber(ARGV[3])

local clearBefore = now - window

-- 1. Hapus catatan timestamp di luar jendela waktu berjalan
redis.call('ZREMRANGEBYSCORE', key, 0, clearBefore)

-- 2. Hitung jumlah request tersisa di dalam jendela berjalan
local currentRequestCount = redis.call('ZCARD', key)

if currentRequestCount < limit then
    -- 3. Jika belum melebihi limit, tambahkan request baru ke Sorted Set
    redis.call('ZADD', key, now, now)
    -- Set TTL otomatis untuk pembersihan memori Redis
    redis.call('PEXPIRE', key, window)
    return {1, limit - currentRequestCount - 1} -- Status Diizinkan
else
    return {0, 0} -- Status Ditolak (Rate Limited)
end

Standar HTTP Response Header & Client Throttling

Ketika permintaan client melebihi kuota yang ditentukan, API harus merespons dengan kode status HTTP 429 Too Many Requests dan menyertakan header standar RFC 6585 agar aplikasi client dapat menyesuaikan laju pengirimannya (backoff mechanism):

HTTP/1.1 429 Too Many Requests
Content-Type: application/json; charset=utf-8
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1779678400

{
    "status": 429,
    "error": "Too Many Requests",
    "message": "Anda telah melebihi batas kuota 100 permintaan per menit. Silakan coba kembali setelah 30 detik.",
    "retry_after_seconds": 30
}

MAYASTRA NAWALOKA

Software Engineering & System Architecture Expert

Spesialis rekayasa perangkat lunak berdedikasi tinggi dalam membangun platform web berkinerja tinggi, sistem terdistribusi, dan arsitektur backend yang scalable untuk perusahaan modern.