Sistem Rate Limiting Global Uber

• Uber membangun Global Rate Limiter (GRL) untuk membentuk sistem perlindungan overload terpadu di lingkungan ribuan microservice yang menangani ratusan juta RPC per detik
• GRL menggunakan arsitektur loop umpan balik 3 lapis yang terdiri dari client-aggregator-controller, sehingga dapat mengambil keputusan permintaan secara lokal sekaligus melakukan koordinasi global dalam hitungan detik
• Uber beralih dari pendekatan token bucket awal ke model drop probabilistik untuk menyelesaikan masalah fairness dan skalabilitas, sambil meminimalkan latensi di hot path
• Dibanding limiter berbasis Redis, latensi P99.5 membaik hingga 90%, dan sistem mampu menyerap lonjakan trafik 15x serta serangan DDoS tanpa degradasi layanan
• Rate Limit Configurator (RLC) menganalisis pola trafik historis dan memperbarui limit secara otomatis, sehingga sistem berevolusi dari konfigurasi statis menjadi sistem yang menyesuaikan diri sendiri

---

Masalah pada rate limiting sebelumnya

• Di lingkungan microservice awal Uber, tiap tim mengimplementasikan throttling sendiri menggunakan logika bisnis, middleware kustom, dan counter berbasis Redis
• Akibatnya muncul masalah seperti konfigurasi yang tidak konsisten, tambahan latensi dari Redis, perlunya redeploy server saat limit diubah, serta sulitnya menangani insiden karena limiter yang tidak terdokumentasi
• Sebagian besar layanan kecil bahkan berjalan tanpa rate limiting, dan tiap limiter melaporkan metrik serta error dengan cara berbeda sehingga observabilitas terpadu tidak bisa diperoleh
• Pendekatan yang memakai Redis sebagai counter terpusat menimbulkan latensi yang tidak dapat diterima dan masalah konsistensi antar-region pada lingkungan dengan ratusan ribu host, ratusan juta request per detik, dan banyak region
  • Bahkan dengan sharding dan replikasi, tetap dibutuhkan ratusan cluster Redis dan itu menambah mode kegagalan baru
• Pendekatan sinkronisasi counter secara periodik memang mengurangi overhead jaringan, tetapi dikesampingkan karena data menjadi kurang segar dan respons terhadap lonjakan trafik mendadak terlambat
• Kesimpulannya, hanya arsitektur terdistribusi penuh, di mana proxy lokal mengambil keputusan berdasarkan beban teragregasi, yang bisa mencapai latensi rendah sekaligus skalabilitas global

Visi limiter terpadu di level infrastruktur

• Solusinya adalah menanamkan rate limiting ke dalam service mesh Uber, yaitu lapisan infrastruktur untuk trafik RPC antar-layanan
• Dengan menyematkan limiter di lapisan ini, semua request dapat diperiksa dan dievaluasi sebelum mencapai tujuan, tanpa bergantung pada bahasa atau framework pemanggil
• Tujuannya: menyediakan layanan rate limiting terpadu yang memungkinkan tim menetapkan kuota per caller dan per procedure tanpa perubahan kode
• Sistem ini harus bisa diskalakan ke ratusan juta request per detik, puluhan ribu pasangan layanan, dan armada host lintas banyak region geografis dengan tambahan latensi seminimal mungkin

Arsitektur GRL: loop umpan balik 3 lapis

• Inti GRL adalah struktur loop umpan balik 3 lapis
  • Rate-limit client (data plane service mesh): mengambil keputusan untuk tiap request secara lokal berdasarkan instruksi dari aggregator, dan melaporkan request per detik per host ke aggregator level zone
  • Aggregator (per zone): mengumpulkan metrik dari semua client dalam zone yang sama, menghitung penggunaan level zone, lalu mengirimkannya ke controller
  • Controller (per region, global): mengagregasi data zone untuk menentukan utilisasi global, lalu menyebarkan kembali instruksi rasio drop yang diperbarui ke aggregator dan client
• Agregasi hierarkis ini memungkinkan latensi rendah di hot path (karena keputusan dibuat secara lokal) sekaligus koordinasi global dalam hitungan detik
• Saat control plane gagal, client bekerja dengan mode fail-open, tetap melewatkan trafik agar tidak memicu gangguan yang dibuat sendiri

Evolusi logika rate limiting

• Pendekatan token bucket awal

  • Pada awalnya, tiap proxy di data plane jaringan menerapkan algoritme token bucket
  • Tiap proxy melacak jumlah request lokal dan mengisi ulang token seiring waktu, lalu mengizinkan atau menolak request berdasarkan jumlah token yang tersedia
  • Laju pengisian ulang token dihitung dari rasio beban lokal proxy terhadap limit global: ratio × limitRPS
  • Untuk menangani burst traffic, token yang tidak terpakai disimpan dalam buffer melingkar, default selama 10 detik (dapat dikonfigurasi hingga 20 detik)
  • Di produksi, muncul masalah fairness dan skalabilitas: saat jumlah caller melebihi limit, kapasitas tidak dapat dibagi secara adil, dan burst traffic pada host tertentu bisa memicu drop lebih awal meski masih di bawah limit global

• Pengenalan Drop-by-Ratio

  • Saat beban global teragregasi melampaui limit yang ditetapkan, client akan men-drop sebagian request secara probabilistik
  • Contoh: jika RPS teragregasi caller adalah 1,5 kali limit, maka sekitar 33% request akan di-drop di semua instance, dengan rumus: drop_ratio = (actual_rps - limit_rps) / actual_rps
  • Dengan sinyal drop global yang diperbarui control plane setiap beberapa detik, trafik yang melebihi batas dapat di-throttle secara merata di semua instance caller
  • Pendekatan ini sangat efektif terutama pada layanan bergaya gateway berskala besar yang memiliki ratusan hingga ribuan instance caller

• Peralihan ke model probabilistik terpadu

  • Seiring GRL makin matang, Uber sepenuhnya meninggalkan token bucket dan menyatukan sistem ke model drop probabilistik berbasis control plane
  • Alasannya, menjalankan dua algoritme sekaligus meningkatkan kompleksitas konfigurasi dan overhead jaringan
  • Dengan model tunggal, konfigurasi disederhanakan, bandwidth control plane dihemat, dan semua keputusan rate limiting disatukan dalam mekanisme yang konsisten secara global
  • Trade-off-nya: sistem bergantung pada data agregat global yang diperbarui tiap detik sehingga ada delay penerapan 2–3 detik
    • Dalam praktiknya, ini dapat diabaikan untuk sebagian besar workload, dan hanya berdampak pada burst yang sangat singkat dan ekstrem

• Desain akhir: drop probabilistik berdasarkan instruksi control plane

  • Pada GRL saat ini, penerapan sepenuhnya terjadi di lapisan client pada data plane jaringan
  • Alur pemrosesan saat request datang:
    • Request dicocokkan ke bucket yang dikonfigurasi (ditentukan oleh caller, procedure, atau keduanya)
    • Jika bucket tersebut memiliki instruksi rasio drop aktif, maka request akan di-drop secara probabilistik sesuai rasio itu
    • Jika tidak ada instruksi drop, request diteruskan seperti biasa
  • Hot path menjadi sangat ringan: tidak perlu perhitungan token lokal atau komunikasi control plane per request, cukup sampling probabilistik sederhana untuk mengambil keputusan in-process
  • Aggregator dan controller menjalankan komputasi yang lebih kompleks (mengagregasi jumlah request, membandingkan ambang batas, menghitung rasio drop baru) setiap detik di luar forwarding plane
  • Desain ini memungkinkan skala ratusan juta request per detik sambil mempertahankan akurasi penerapan global dalam hitungan detik

Konfigurasi limit

• Pemilik layanan mendefinisikan bucket rate limiting dalam file konfigurasi
  • Scope: global, per region, per zone
  • Aturan pencocokan: nama caller, procedure, atau keduanya
  • Perilaku: deny (diterapkan) atau allow (shadow mode untuk pengujian)
• Diterapkan secara transparan ke layanan tujuan tanpa perubahan kode

Hasil operasional

• Penurunan latensi dan penghapusan overhead

  • Sebelum GRL, banyak layanan menggunakan limiter berbasis Redis yang membutuhkan network round trip untuk setiap request
  • Dengan beralih ke evaluasi lokal di data plane service mesh, hop tambahan dihilangkan dan latensi turun drastis
  • Latensi P50 turun sekitar 1 ms, P90 turun puluhan ms, dan pada P99.5 berkurang dari ratusan ms menjadi puluhan ms dengan peningkatan hingga 90%

• Penyederhanaan operasional dan efisiensi sumber daya

  • Sentralisasi rate limiting di dalam data plane service mesh menyederhanakan infrastruktur
  • Tidak diperlukan lagi data store atau lapisan cache terpisah untuk menerapkan kuota
  • Sejumlah besar instance Redis yang sebelumnya didedikasikan untuk rate limiting dapat dihentikan, menghasilkan efisiensi komputasi yang berarti

• Peningkatan stabilitas dan respons insiden

  • Setelah diterapkan, GRL berulang kali mencegah overload saat spike, failover, dan retry storm
  • Dengan melakukan shedding terhadap trafik berlebih secara probabilistik di service mesh, waktu respons tetap konsisten meski terjadi lonjakan beban masuk secara tajam
  • Layanan inti mampu menangani lonjakan trafik 15x dari 22K ke 367K RPS tanpa degradasi
  • Serangan DDoS dapat diserap sebelum mencapai sistem internal
  • Saat respons insiden, tim production engineering menggunakan GRL untuk menerapkan rate limit terarah pada caller/procedure tertentu dengan trafik tinggi; pembaruan control plane tersebar setiap detik sehingga overload dapat ditangani dalam hitungan detik
  • Pola trafik tertentu dapat di-throttle dengan cepat dan aman tanpa redeploy layanan
  • Skala keseluruhan: sekitar 80 juta request per detik, dengan kuota dinamis diterapkan di lebih dari 1.100 layanan

Otomatisasi rate limiting: Rate Limit Configurator (RLC)

• Batasan konfigurasi manual

  • Walaupun GRL menyatukan penerapan, penetapan limit masih membutuhkan pekerjaan manual
  • Pemilik layanan mendefinisikan kuota per caller dan per procedure dalam file YAML lalu menyesuaikannya setiap kali pola trafik berubah
  • Dalam lingkungan dengan ratusan microservice yang terus berevolusi, konfigurasi statis cepat menjadi kedaluwarsa
    • Jika terlalu ketat, throttling dapat terjadi bahkan saat puncak trafik normal
    • Jika terlalu longgar, limit menjadi terlalu tinggi dibanding kapasitas nyata sehingga perlindungannya minim
    • Perubahan bergantung pada analisis dashboard dan tuning manual

• Cara kerja RLC

  • RLC (Rate Limit Configurator) menjaga konfigurasi GRL tetap mutakhir secara otomatis
  • Berdasarkan jadwal tetap atau segera setelah perubahan konfigurasi, sistem menjalankan siklus berikut:
    • Mengumpulkan metrik beberapa minggu terakhir dari platform observabilitas Uber
    • Menghitung limit aman per caller dan per procedure dengan memanfaatkan puncak historis dan buffer cadangan
    • Menulis konfigurasi yang diperbarui ke shared configuration store
    • Mendorong limit baru ke GRL melalui control plane yang sudah ada
  • Dengan proses closed loop ini, limit berevolusi mengikuti trafik nyata sambil meminimalkan intervensi manual

• Desain yang dapat diskalakan

  • Sejak awal, RLC dirancang untuk mendukung berbagai strategi perhitungan rate limit
  • Kebijakan default berbasis data RPS historis, tetapi tipe kebijakan baru dapat ditambahkan secara modular
  • Layanan seperti data pemetaan dan lokasi menggunakan model prediktif yang mempertimbangkan prakiraan trafik dan kapasitas yang telah direncanakan, bukan sekadar tren historis
  • Sistem juga mendukung alokasi kuota tetap berdasarkan kesepakatan kontraktual atau operasional yang telah ditentukan sebelumnya
  • Melalui antarmuka modular, tiap domain layanan dapat memilih logika perhitungan yang sesuai, baik pola trafik hampir real-time, prediksi, maupun kuota statis

• Shadow mode dan validasi

  • Demi keamanan, limit dapat dibuat dan dipantau dalam shadow mode tanpa benar-benar diterapkan
  • Pemilik layanan dapat mengamati perilaku rate limiting di produksi sebelum mengaktifkannya
  • Dashboard dan alert khusus memvisualisasikan trafik yang diamati serta virtual drop agar kepercayaan diri tercapai sebelum rollout

• Dampak otomatisasi

  • Ribuan aturan rate limiting diperbarui secara otomatis tanpa pengeditan manual
  • Kebijakan yang konsisten dapat dihasilkan di semua layanan dengan rumus dan sumber data yang sama
  • Berbagai tipe kebijakan memungkinkan tim memilih dan memperluas logika perhitungan yang paling sesuai untuk workload mereka
  • Akurasi terjamin sebelum penerapan lewat shadow mode

Arah selanjutnya

• Setelah RLC diperkenalkan, Uber terus memperluas buffer tuning, memperkenalkan rate limit per region untuk mengurangi cakupan dampak perubahan konfigurasi, dan meningkatkan frekuensi pembaruan agar lebih responsif terhadap trafik langsung
• Lapisan throttler Uber memberikan perlindungan overload tambahan lebih dekat ke aplikasi
• Saat ini, GRL adalah komponen inti dari stability stack berlapis Uber untuk menjaga stabilitas dan fairness platform bahkan di bawah beban ekstrem