Token Bucket vs Leaky Bucket: Memilih Algoritma Rate Limiting API

API yang melayani banyak pengguna perlu memastikan satu klien tidak menghabiskan kapasitas server untuk semua orang. Rate limiting membatasi jumlah permintaan yang boleh dilakukan dalam periode tertentu. Dua algoritma yang umum dipakai adalah Token Bucket dan Leaky Bucket. Keduanya mengendalikan trafik, tetapi memberikan hasil berbeda ketika permintaan datang secara beruntun.

Memahami perbedaan tersebut membantu pengembang memilih kebijakan yang sesuai: apakah sistem perlu memberi ruang untuk lonjakan singkat atau membutuhkan aliran pekerjaan yang lebih rata.

Apa itu rate limiting API?

Rate limiting menetapkan batas berdasarkan identitas tertentu, seperti API key, akun, organisasi, alamat IP, atau endpoint. Ketika batas terlampaui, server dapat menolak permintaan sementara dengan status HTTP 429 Too Many Requests. Jika waktu pemulihan bisa ditentukan, respons dapat menyertakan header Retry-After agar klien tahu kapan sebaiknya mencoba kembali.

Batas tidak harus sama untuk semua operasi. Endpoint pencarian sederhana mungkin dapat menerima lebih banyak permintaan dibandingkan endpoint ekspor besar atau operasi yang memanggil layanan AI. Karena itu, kebijakan yang baik mempertimbangkan biaya operasi, tingkat layanan, dan pola penggunaan yang wajar.

Cara kerja Token Bucket

Token Bucket dapat dibayangkan sebagai wadah yang diisi token secara berkala. Setiap permintaan membutuhkan token. Jika token mencukupi, permintaan diizinkan dan token dikurangi. Jika tidak tersedia, permintaan ditolak atau ditunda sesuai kebijakan aplikasi.

Misalnya, bucket memiliki kapasitas 60 token dan terisi kembali dengan laju satu token per detik. Klien dapat mengirim hingga 60 permintaan sekaligus jika bucket sebelumnya penuh. Setelah itu, permintaan baru hanya dapat diterima seiring token tersedia. Algoritma ini mengizinkan lonjakan singkat, tetapi tetap membatasi rata-rata penggunaan dalam jangka panjang.

Token Bucket cocok untuk API yang mengalami trafik tidak merata, misalnya aplikasi seluler yang menyinkronkan data setelah perangkat kembali online. Kapasitas bucket mengatur ukuran lonjakan yang diizinkan, sedangkan laju pengisian menentukan penggunaan rata-rata. Jika biaya endpoint berbeda, satu permintaan dapat mengonsumsi lebih dari satu token.

Cara kerja Leaky Bucket

Leaky Bucket memakai gambaran wadah yang mengeluarkan air dengan laju tetap. Permintaan yang masuk ditempatkan dalam antrean, lalu diproses sesuai kecepatan yang ditentukan. Jika antrean penuh, permintaan baru ditolak. Sebagian implementasi menggunakan istilah yang sama untuk pembatas laju tanpa antrean eksplisit, sehingga detail algoritma pada produk yang digunakan perlu diperiksa.

Model antrean berguna ketika layanan di belakang API membutuhkan aliran kerja stabil, misalnya pengiriman pekerjaan ke sistem lama, pemrosesan berkas, atau tugas yang membebani sumber daya secara konsisten. Namun, antrean menambah latensi dan memerlukan batas panjang serta kebijakan kedaluwarsa. Tanpa batas yang jelas, permintaan hanya menumpuk dan pengguna menunggu terlalu lama.

Perbedaan yang perlu dipahami

• Lonjakan trafik: Token Bucket mengizinkan burst selama token tersedia. Leaky Bucket dengan antrean meratakan pekerjaan mengikuti laju pemrosesan.
• Latensi: Token Bucket biasanya memberi respons cepat saat token tersedia. Leaky Bucket dapat menambah waktu tunggu saat antrean panjang.
• Perilaku saat penuh: Token Bucket menolak atau menunda permintaan yang tidak memiliki token. Leaky Bucket menolak permintaan ketika antrean mencapai kapasitas.
• Kebutuhan utama: Token Bucket cocok untuk API interaktif dengan pola trafik berubah-ubah. Leaky Bucket cocok ketika kestabilan laju pemrosesan lebih penting daripada respons instan.

Tidak ada algoritma yang selalu lebih baik. Token Bucket mengendalikan rata-rata permintaan sambil memberi ruang untuk burst. Leaky Bucket membantu meratakan laju pekerjaan, tetapi antrean harus dikelola agar tidak menjadi sumber latensi baru.

Cara memilih dan menerapkannya

1. Ukur biaya endpoint. Catat latensi, penggunaan CPU, kueri database, dan biaya layanan eksternal. Jangan menetapkan batas hanya berdasarkan angka permintaan tanpa memahami dampaknya.
2. Tentukan identitas pembatas. API key atau akun biasanya lebih adil bagi pengguna terautentikasi yang berbagi alamat IP. Pembatasan IP tetap berguna untuk trafik anonim, tetapi pertimbangkan NAT dan jaringan bersama.
3. Atur burst dan laju rata-rata. Untuk Token Bucket, pilih kapasitas dan laju pengisian berdasarkan lonjakan yang masih dapat ditangani server. Untuk Leaky Bucket, tentukan laju pemrosesan dan panjang antrean yang masuk akal.
4. Jaga konsistensi di banyak server. Penghitung lokal di setiap proses dapat membuat batas efektif menjadi berlipat. Gunakan penyimpanan bersama seperti Redis atau mekanisme terdistribusi lain, dan lakukan pembaruan secara atomik agar permintaan serentak tidak melewati batas.
5. Rancang respons yang jelas. Kembalikan HTTP 429 saat batas terlampaui dan, jika memungkinkan, sertakan Retry-After. Dokumentasikan apakah klien perlu menunggu, mengurangi frekuensi, atau mengantrekan pekerjaan.
6. Uji kondisi nyata. Simulasikan trafik normal, lonjakan mendadak, beberapa server, perbedaan jam sistem, serta kegagalan penyimpanan penghitung. Pastikan kegagalan pembatas tidak tanpa sengaja membuka akses tanpa batas.

Kesimpulan

Token Bucket dan Leaky Bucket sama-sama membantu mengendalikan laju permintaan, tetapi perilakunya berbeda: token bucket mengizinkan lonjakan terbatas, sedangkan leaky bucket membantu meratakan keluaran. Pilih berdasarkan pola trafik dan kebutuhan layanan, lalu uji batas konkurensi, konsistensi penghitung, serta respons saat backend pembatas mengalami gangguan.