54 Menambahkan Rate Limiting dan Throttling
Mengelola lalu lintas jaringan ke aplikasi adalah salah satu aspek penting dalam pengembangan perangkat lunak berbasis layanan, khususnya API. Seiring dengan bertumbuhnya pengguna, API harus tetap dapat diandalkan dan aman dari penyalahgunaan atau serangan. Dua teknik yang sering digunakan untuk solusi ini adalah rate limiting dan throttling. Artikel ini mengajak Anda memahami, membedakan, dan mengimplementasi keduanya, lengkap dengan contoh kode, simulasi, serta visualisasi sederhana.
Apa Itu Rate Limiting dan Throttling?
Rate Limiting
Rate limiting adalah teknik untuk membatasi jumlah permintaan (requests) yang bisa dilakukan ke server dalam periode waktu tertentu. Misalnya, maksimal 100 requests per menit per user.
Throttling
Throttling adalah proses memperlambat atau menunda permintaan yang berlebih, daripada langsung menolaknya. Dalam throttling, request tetap diproses namun dengan jeda tertentu sehingga server tidak overload.
Perbedaan mendasar:
- Rate limiting biasanya “menolak” permintaan begitu melebihi limit.
- Throttling “melambatkan” permintaan, namun tidak langsung menolaknya.
Teknik | Tindakan ketika limit terlampaui | Contoh Respons |
---|---|---|
Rate Limiting | Request ditolak (HTTP 429) | {"error": "Too Many Requests"} |
Throttling | Request diproses lebih lambat | Latency meningkat, respons tetap diterima |
Mengapa Perlu Rate Limiting dan Throttling?
- Meningkatkan keamanan: Mencegah serangan brute force, DDoS, dan API scraping.
- Menjaga stabilitas server: Beban tidak tiba-tiba melonjak.
- Mengatur pengalaman pengguna: Tidak satu user mendominasi.
- Kontrol biaya: Terutama saat menggunakan layanan berbayar per request.
Strategi Implementasi
Beberapa strategi rate limiting populer:
- Fixed Window — Menghitung request dalam window waktu tetap (misal setiap 1 menit).
- Sliding Window — Mirip fixed window, tapi lebih luwes.
- Token Bucket — Setiap request “menghabiskan token”. Token diisi ulang periodik.
- Leaky Bucket — Request diproses stabil lewat queue, mirip throttling.
Diagram perbedaan Fixed Window dan Token Bucket:
sequenceDiagram participant User participant API participant Bucket User->>API: Send Request API->>Bucket: Check Token alt Token available Bucket->>API: Take Token API->>User: Process Request else No token API->>User: 429 Error (Rate Limited) end
Studi Kasus: Implementasi di Node.js dengan ExpressJS
Instalasi Middleware
Untuk kepraktisan, kita gunakan express-rate-limit.
npm install express express-rate-limit
Contoh Implementasi Rate Limiting
const express = require('express');
const rateLimit = require('express-rate-limit');
const app = express();
// Atur rate limit: max 10 request per 15 detik per IP
const limiter = rateLimit({
windowMs: 15 * 1000, // 15 detik
max: 10,
message: {
error: "Too many requests, please try again later."
}
});
app.use(limiter);
app.get('/api/data', (req, res) => {
res.json({ success: true, message: 'Data received!' });
});
app.listen(3000, () => console.log('Server up on port 3000'));
Simulasi: Jika seorang user melakukan lebih dari 10 permintaan dalam 15 detik, seluruh permintaan berikutnya akan memperoleh respons:
{ "error": "Too many requests, please try again later." }
Implementasi Throttling Sederhana
Throttling dapat dibuat dengan memperlambat response menggunakan setTimeout
. Ini bukan teknik optimal, namun cukup ilustratif.
const slowDown = (req, res, next) => {
// Simulasi: jika jumlah request lebih dari 5 dalam semenit, delay 1 detik
if (!req.session) req.session = {};
req.session.requests = req.session.requests || [];
const now = Date.now();
// hapus request yang lebih dari 1 menit lalu
req.session.requests = req.session.requests.filter(ts => now - ts < 60 * 1000);
req.session.requests.push(now);
if (req.session.requests.length > 5) {
setTimeout(next, 1000); // delay 1 detik
} else {
next();
}
};
app.use(slowDown);
Dengan middleware di atas:
- User normal: respons cepat < 5 request/menit.
- User overused: setiap request >5/menit tertunda 1 detik.
Simulasi & Tabel Uji
Pengujian dengan HTTP Client Sederhana:
for i in {1..12}; do curl -i http://localhost:3000/api/data; done
Request Ke- | Fixed Window (10/15s) | Time (Throttled after 5/min) |
---|---|---|
1 - 10 | 200 OK | 0 ms (cepat) |
11 - 12 | 429 Too Many Requests | 1000 ms (delay 1 detik) |
Best Practices
1. Gunakan Redis untuk distribusi skala-besar
Middleware rate limiter baik untuk dev/test, namun untuk production dan skala distribusi, gunakan Redis agar konsisten di beberapa instance server.
2. Granularitas Limiting
Anda bisa limit berdasarkan:
- IP address
- API key
- User ID
- Endpoint
Sesuaikan dengan kasus penggunaan.
3. Return Informasi Limit
Return header rate-limit agar client tahu batasan mereka:
HTTP/1.1 200 OK
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 3
X-RateLimit-Reset: 1717462200
4. Consider Burst & Throttle
Biarkan burst kecil lewat cepat, setelah itu throttle, bukan reject, agar UX tetap smooth.
Penutup
Menerapkan rate limiting dan throttling adalah langkah wajib untuk keandalan API modern—melindungi dari overload, serangan, dan menjaga keadilan antar pengguna. Mengintegrasikannya mudah dieri dengan bantuan middleware, namun kunci sukses ada pada pemilihan strategi, tuning parameter, serta monitoring.
Jangan lupa, rate limiting dan throttling bukan solusi semua masalah—kombinasikan dengan caching, monitoring, dan alerting untuk API yang benar-benar andal.
Jika Anda ingin simulasi kode lebih advanced atau menggunakan Redis, sampaikan di komentar atau DM saya! Selamat membangun API yang sehat dan skalabel. 🚀
76. Menyambungkan gRPC Service dengan Kafka
Artikel Terhangat
56 Apa Itu Subscription di GraphQL?
08 Aug 2025
78. Men-deploy gRPC Service di Docker
08 Aug 2025
77. gRPC di Kubernetes dengan LoadBalancer
08 Aug 2025
54 Menambahkan Rate Limiting dan Throttling
08 Aug 2025
76. Menyambungkan gRPC Service dengan Kafka
08 Aug 2025

56 Apa Itu Subscription di GraphQL?

78. Men-deploy gRPC Service di Docker

77. gRPC di Kubernetes dengan LoadBalancer

54 Menambahkan Rate Limiting dan Throttling
