tutorial

54 Menambahkan Rate Limiting dan Throttling

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.
TeknikTindakan ketika limit terlampauiContoh Respons
Rate LimitingRequest ditolak (HTTP 429){"error": "Too Many Requests"}
ThrottlingRequest diproses lebih lambatLatency 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:

  1. Fixed Window — Menghitung request dalam window waktu tetap (misal setiap 1 menit).
  2. Sliding Window — Mirip fixed window, tapi lebih luwes.
  3. Token Bucket — Setiap request “menghabiskan token”. Token diisi ulang periodik.
  4. 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 - 10200 OK0 ms (cepat)
11 - 12429 Too Many Requests1000 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. 🚀

comments powered by Disqus