Rate Limiting vs Throttling: Dua Senjata Utama Mengendalikan Traffic di Sistem Skala Besar

Di dunia nyata, traffic tidak pernah ideal. Request bisa datang:

• Dalam burst besar (flash sale, viral event)
• Secara perlahan tapi konsisten
• Dari user normal, bot, hingga attacker

Tanpa mekanisme pengendalian, sistem yang secara teori kuat bisa runtuh hanya karena satu jenis traffic yang salah.

Di sinilah dua konsep penting muncul:

• Rate Limiting → mengontrol berapa banyak request yang boleh masuk
• Throttling → mengontrol seberapa cepat request diproses

Keduanya sering dipakai bersamaan, tapi salah desain sedikit saja bisa berdampak langsung ke availability, latency, bahkan revenue.

Artikel ini membedah keduanya secara lebih dalam—bukan sekadar definisi, tapi cara berpikir engineer produksi. Dalam sistem modern—terutama API, microservices, dan platform berskala besar—mengontrol traffic adalah kebutuhan mutlak. Tanpa kontrol, satu klien saja bisa:

• Menghabiskan resource server
• Menyebabkan denial of service (baik sengaja maupun tidak)
• Membuat sistem tidak adil bagi pengguna lain

Dua istilah yang sering muncul dalam konteks ini adalah Rate Limiting dan Throttling. Keduanya sering disamakan, padahal tujuan, perilaku, dan use case-nya berbeda.

Artikel ini akan membahas:

• Definisi dan konsep masing-masing
• Perbedaan mendasar
• Contoh implementasi nyata
• Kapan sebaiknya menggunakan rate limit, throttling, atau kombinasi keduanya

Gambaran Singkat (Diagram Konseptual)

Client
  |
  |  Request
  v
[ Rate Limit Check ] ---> Reject (429 Too Many Requests)
  |
  v
[ Throttling Control ] ---> Delay / Slow Down
  |
  v
Backend Service

Intinya:

• Rate limit = boleh atau tidak
• Throttling = seberapa cepat

Apa Itu Rate Limiting?

Definisi Konseptual

Rate limiting adalah mekanisme proteksi yang membatasi jumlah maksimum request dari suatu entitas (user, IP, API key, device, tenant) dalam interval waktu tertentu.

Secara mental model:

“Jika kamu sudah pakai jatahmu, request berikutnya tidak boleh masuk.”

Definisi

Rate limiting adalah mekanisme untuk membatasi jumlah request yang boleh dilakukan oleh client dalam periode waktu tertentu.

Contoh:

• Maksimal 100 request per menit per user
• Maksimal 10 request per detik per IP

Jika limit terlampaui, request langsung ditolak.

Karakteristik Utama Rate Limiting

• Deterministik: hasilnya jelas, lolos atau ditolak
• Boundary-level control: ideal ditempatkan di edge (API Gateway, CDN)
• Fail fast: sistem backend tidak ikut terbebani
• Security-oriented: sering dipakai sebagai lapisan mitigasi serangan
• Bersifat hard limit
• Biasanya menghasilkan error HTTP 429 (Too Many Requests)
• Tidak ada penundaan, hanya accept atau reject
• Sering digunakan untuk proteksi dan fairness

Algoritma Umum Rate Limiting

1. Fixed Window Counter

   • Counter di-reset tiap window waktu
   • Murah dan simpel
   • Masalah utama: boundary burst

2. Sliding Window Log

   • Simpan timestamp tiap request
   • Akurat, tapi mahal memory

3. Sliding Window Counter

   • Kompromi antara akurasi dan biaya
   • Banyak dipakai di API Gateway modern

4. Token Bucket

   • Mendukung burst terkontrol
   • Sangat populer untuk API publik

5. Leaky Bucket (Hard Limit Mode)

   • Kapasitas tetap
   • Request overflow langsung ditolak

6. Fixed Window

   • Hitung request per window waktu
   • Mudah, tapi bisa burst di boundary

7. Sliding Window

   • Lebih akurat
   • Lebih mahal secara komputasi

8. Token Bucket

   • Token diisi periodik
   • Request butuh 1 token

9. Leaky Bucket (versi limit)

   • Antrian dengan kapasitas terbatas

Use Case Nyata Rate Limiting (Produksi)

1. Public API & SaaS Platform

Digunakan untuk:

• Mencegah abuse
• Menjaga SLA
• Monetisasi berbasis tier

Contoh nyata:

Free  : 60 req/min
Pro   : 600 req/min
Enterprise: custom

2. Authentication & Security Endpoint

Endpoint paling sensitif:

• Login
• OTP
• Password reset

Rate limit mencegah:

• Brute force
• Credential stuffing

3. Multi-Tenant Fairness

Tanpa rate limit:

• Satu tenant rakus → tenant lain menderita

Rate limit menjaga isolasi logical antar tenant.

4. Fair Usage Policy

• Semua user mendapat jatah yang adil
• Tidak ada “noisy neighbor”

Kapan Rate Limiting Tepat Digunakan?

Gunakan rate limiting jika:

• Request berlebihan tidak boleh diproses sama sekali
• Sistem harus tegas dan deterministik
• Fokus pada keamanan dan proteksi resource

Apa Itu Throttling?

Definisi Konseptual

Throttling adalah mekanisme untuk mengatur laju pemrosesan ketika beban mendekati atau melewati kapasitas sistem.

Mental model-nya berbeda:

“Aku tetap terima request-mu, tapi aku akan memprosesnya pelan-pelan.”

Definisi

Throttling adalah mekanisme untuk memperlambat request ketika traffic terlalu tinggi, bukan menolaknya secara langsung.

Request tetap diproses, tetapi:

• Ditunda
• Diperlambat
• Diproses secara bertahap

Karakteristik Utama Throttling

• Adaptive: sering bergantung pada kondisi runtime
• Internal-facing: umum di service-to-service
• Stability-first: mengorbankan latency demi availability
• Queue-aware: hampir selalu berkaitan dengan antrian
• Bersifat soft control
• Fokus pada stabilitas sistem
• Mengatur flow, bukan jumlah total
• Sering tidak terlihat langsung oleh client

Cara Kerja Throttling (Ilustrasi)

Incoming Requests: ||||||||||||||||

Allowed Processing Rate:
|||||     |||||     |||||

Excess request → masuk queue → diproses perlahan

Mekanisme Throttling yang Umum (Dengan Implikasi)

1. Queue-based Throttling

   • Sederhana
   • Risiko memory pressure

2. Concurrency Limiting

   • Batasi worker aktif
   • Cocok untuk CPU-bound task

3. Adaptive / Dynamic Throttling

   • Berdasarkan latency, CPU, error rate
   • Digunakan di service mesh modern

4. Backpressure Propagation

   • Downstream memberi sinyal ke upstream
   • Sangat penting di arsitektur reaktif

5. Queue-based Throttling

   • Request masuk antrian
   • Diproses sesuai kapasitas

6. Concurrency Limiting

   • Batasi jumlah proses aktif

7. Adaptive Throttling

   • Berdasarkan CPU, memory, latency

8. Backpressure

   • Sistem downstream meminta upstream melambat

Use Case Nyata Throttling (Produksi)

1. Microservices & Service Mesh

Tanpa throttling:

• Service lambat → retry → storm → cascade failure

Dengan throttling:

• Sistem melambat terkontrol

2. Background Processing & Event Consumer

Contoh:

• Kafka consumer
• SQS worker

Lebih baik:

• Backlog naik Daripada:
• Service crash

3. Financial & Mission-Critical System

• Transaksi tidak boleh hilang
• Latency bisa ditoleransi

Throttling adalah pilihan logis.

4. Sistem Internal & Microservices

Contoh:

• Service A memanggil Service B
• Jika Service B overload, A diperlambat

Tujuan:

• Mencegah cascading failure

5. Background Job & Worker

Contoh:

• Email sender
• Push notification
• Video transcoding

Lebih baik lambat daripada gagal.

6. Payment & Financial Processing

• Tidak boleh drop transaksi
• Lebih aman diproses pelan

Kapan Throttling Tepat Digunakan?

Gunakan throttling jika:

• Request tetap harus diproses
• Stabilitas lebih penting dari kecepatan
• Sistem perlu adaptif terhadap load

Perbedaan Fundamental Rate Limiting vs Throttling

Mengapa Sistem Nyata Hampir Selalu Membutuhkan Keduanya

Mengandalkan salah satu saja adalah design smell.

Pola Arsitektur Produksi

• Rate limit → melindungi pintu masuk
• Throttling → melindungi organ dalam

Hasilnya:

• Backend tidak kaget
• Client tidak semena-mena
• Sistem tetap bernapas

Dalam sistem produksi, rate limiting dan throttling hampir selalu dipakai bersama.

Contoh Arsitektur Nyata

Client
  |
  v
[ API Gateway ]
  |- Rate Limit per User/IP
  v
[ Service Mesh / Load Balancer ]
  |- Throttling per Service
  v
[ Backend Services ]

Alasan Kombinasi Ini Efektif

• Rate limit → proteksi dari abuse
• Throttling → proteksi dari overload internal

Anti-Pattern yang Perlu Dihindari

1. Hanya Rate Limit Tanpa Throttling

   • Internal service bisa tetap overload

2. Throttling Tanpa Batas

   • Queue bisa menumpuk dan kehabisan memory

3. Limit Terlalu Ketat

   • User experience buruk

Best Practice

• Gunakan rate limiting di boundary (API Gateway)
• Gunakan throttling di internal system
• Sesuaikan limit dengan tier user
• Monitor metrik: latency, queue length, error rate
• Dokumentasikan limit ke consumer API

Penutup

Engineer junior sering bertanya:

“Mana yang lebih baik, rate limiting atau throttling?”

Engineer senior tahu jawabannya:

“Tergantung di mana kamu berdiri di arsitektur.”

Rate limiting menjaga disiplin eksternal. Throttling menjaga ketenangan internal.

Menguasai keduanya berarti kamu tidak hanya membangun sistem yang jalan, tapi sistem yang bertahan di kondisi terburuk.

Rate limiting dan throttling bukanlah musuh, tapi pasangan.

• Rate limiting menjawab: boleh atau tidak?
• Throttling menjawab: seberapa cepat?

Memahami perbedaan dan use case nyata keduanya akan membuat sistem:

• Lebih stabil
• Lebih aman
• Lebih scalable

Dan yang paling penting: lebih siap menghadapi dunia nyata yang penuh traffic tak terduga 🚦