Uber की ग्लोबल rate limiting system

• Uber ने प्रति सेकंड सैकड़ों मिलियन RPCs संभालने वाले हजारों microservices के वातावरण में Global Rate Limiter (GRL) बनाकर एकीकृत overload protection framework स्थापित किया
• GRL, client-aggregator-controller से बना 3-tier feedback loop architecture है, जो requests पर लोकल स्तर पर निर्णय लेते हुए भी कुछ सेकंड के भीतर global coordination संभव बनाता है
• शुरुआती token bucket पद्धति से probabilistic drop model में बदलाव करके fairness और scalability की समस्याएँ हल की गईं और hot path latency को न्यूनतम किया गया
• Redis-आधारित limiter की तुलना में P99.5 latency में अधिकतम 90% सुधार हुआ, और 15x traffic surge तथा DDoS attacks को भी service degradation के बिना absorb किया गया
• Rate Limit Configurator (RLC) पिछले traffic patterns का विश्लेषण करके limits को अपने-आप अपडेट करता है, जिससे static configuration से self-adjusting system की ओर विकास हुआ

---

मौजूदा rate limiting की समस्याएँ

• Uber के शुरुआती microservices environment में हर team ने business logic, custom middleware, Redis-based counters आदि के जरिए throttling अपने-अपने तरीके से लागू की
• इससे असंगत configurations, Redis-आधारित अतिरिक्त latency, limit बदलने पर server redeploy की आवश्यकता, और undocumented limiters के कारण incident response में कठिनाई जैसी समस्याएँ पैदा हुईं
• काफी छोटे services तो बिना किसी rate limiting के चल रहे थे, और हर limiter metrics व errors को अलग-अलग रिपोर्ट करता था, इसलिए unified observability संभव नहीं थी
• Redis को centralized counter के रूप में इस्तेमाल करने का तरीका, सैकड़ों हजार hosts, प्रति सेकंड सैकड़ों मिलियन requests और multi-region environment in अस्वीकार्य latency तथा cross-region consistency समस्याएँ पैदा करता था
  • Sharding और replication लगाने पर भी सैकड़ों Redis clusters की आवश्यकता पड़ती, और नए failure modes जुड़ जाते
• Counters की periodic synchronization पद्धति network overhead तो कम करती थी, लेकिन stale data और अचानक traffic spike पर धीमी प्रतिक्रिया के कारण इसे भी खारिज कर दिया गया
• अंततः निष्कर्ष यह निकला कि केवल पूरी तरह distributed architecture, जिसमें local proxies aggregated load के आधार पर निर्णय लें, वही low latency और global scalability दोनों साथ दे सकती है

एकीकृत infrastructure-level limiter का विज़न

• समाधान यह था कि Uber के service mesh में rate limiting को embed किया जाए, जो service-to-service RPC traffic के लिए infrastructure layer है
• इस layer में limiter embed करने से caller की language या framework से स्वतंत्र रूप से सभी requests को destination तक पहुँचने से पहले inspect और evaluate किया जा सकता है
• लक्ष्य: code changes के बिना teams को caller-wise और procedure-wise quotas सेट करने की सुविधा देने वाली unified rate limiting service उपलब्ध कराना
• इसे प्रति सेकंड सैकड़ों मिलियन requests, tens of thousands service pairs, और कई geographic regions के host fleet में न्यूनतम latency overhead के साथ scale करना था

GRL architecture: 3-tier feedback loop

• GRL का मूल 3-tier feedback loop structure है
  • Rate-limit client (service mesh data plane): aggregator से मिले निर्देशों के अनुसार लोकल स्तर पर per-request decisions लेता है, और host-wise requests per second को zone-level aggregator को रिपोर्ट करता है
  • Aggregator (per zone): उसी zone के सभी clients के metrics इकट्ठा करता है, zone-level usage निकालकर controller को भेजता है
  • Controller (per region, global): zone data aggregate करके global utilization तय करता है, और updated drop ratio instructions को aggregator व client तक वापस propagate करता है
• इस hierarchical aggregation से hot path में low latency (क्योंकि decision local है) बनाए रखते हुए कुछ सेकंड के भीतर global coordination हासिल किया गया
• Control plane failure की स्थिति में client fail-open मोड में काम करता है, यानी traffic को गुजरने देता है ताकि self-inflicted outage न हो

rate limiting logic का विकास

• शुरुआती token bucket तरीका

  • शुरुआत में network data plane के हर proxy पर token bucket algorithm लागू किया गया
  • हर proxy लोकल request count track करता था और समय के साथ tokens refill करता था, फिर उपलब्ध tokens के आधार पर requests allow या reject की जाती थीं
  • Token refill rate, proxy के local load और global limit के अनुपात से निकाली जाती थी: ratio × limitRPS
  • Burst traffic संभालने के लिए unused tokens को circular buffer में रखा जाता था, जो default 10 seconds तक और अधिकतम 20 seconds तक retain हो सकता था
  • Production में fairness और scalability समस्याएँ सामने आईं: जब callers की संख्या limit से अधिक होती, तो capacity का fair distribution संभव नहीं था, और individual hosts के burst traffic पर global limit से नीचे होने पर भी early drops हो जाते थे

• Drop-by-Ratio की शुरुआत

  • जब aggregated global load configured limit से ऊपर जाता, तो client probabilistically requests का एक निश्चित हिस्सा drop करता
  • उदाहरण: अगर caller का aggregated RPS limit का 1.5x हो, तो सभी instances पर लगभग 33% drops होंगे; formula: drop_ratio = (actual_rps - limit_rps) / actual_rps
  • Control plane हर कुछ सेकंड में जो global drop signal अपडेट करता है, उसके जरिए excess traffic को सभी caller instances में समान रूप से throttle किया जाता है
  • यह खासकर सैकड़ों से हजारों caller instances वाले बड़े gateway-style services में प्रभावी रहा

• एकीकृत probabilistic model की ओर बदलाव

  • GRL के परिपक्व होने के साथ token bucket को पूरी तरह हटाकर control-plane-based probabilistic drop model अपनाया गया
  • क्योंकि दोनों algorithms साथ चलाने से configuration complexity और network overhead बढ़ रहे थे
  • Single model में एकीकरण से configuration सरल हुई, control plane bandwidth कम हुई, और सभी rate limiting decisions globally consistent mechanism के तहत आ गईं
  • Trade-off: हर सेकंड अपडेट होने वाले global aggregated data पर निर्भरता के कारण 2–3 seconds की enforcement delay आती है
    • व्यवहार में यह अधिकांश workloads के लिए नगण्य है, और असर केवल बहुत छोटे व अत्यधिक bursty cases में दिखता है

• अंतिम design: control plane निर्देशित probabilistic drop

  • मौजूदा GRL में enforcement पूरी तरह network data plane की client layer में होती है
  • Request आने पर processing flow:
    • Request को configured bucket से match किया जाता है, जो caller, procedure, या दोनों से परिभाषित हो सकता है
    • अगर उस bucket पर active drop ratio instruction है, तो उसी ratio के अनुसार probabilistic drop किया जाता है
    • अगर drop instruction नहीं है, तो request सामान्य रूप से आगे भेज दी जाती है
  • Hot path बेहद lightweight है: न local token computation की ज़रूरत, न per-request control plane communication; in-process decision के लिए सिर्फ simple probabilistic sampling
  • Aggregator और controller forwarding plane के बाहर हर सेकंड जटिल calculations करते हैं, जैसे request counts aggregate करना, thresholds compare करना, और नए drop ratios निकालना
  • इस design से प्रति सेकंड सैकड़ों मिलियन requests तक scale करते हुए भी कुछ सेकंड के भीतर global enforcement accuracy बनाए रखी गई

limits सेट करना

• Service owners configuration file में rate limit buckets define करते हैं
  • Scope: global, per region, per zone
  • Matching rules: caller name, procedure, या दोनों
  • Behavior: deny (enforce) या allow (testing के लिए shadow mode)
• यह destination service पर बिना code changes के पारदर्शी रूप से लागू होता है

operational results

• latency में कमी और overhead का हटना

  • GRL से पहले कई services हर request पर network round-trip की ज़रूरत वाले Redis-based limiters इस्तेमाल करते थे
  • Service mesh data plane में local evaluation पर जाने से अतिरिक्त hops हटे और latency में बड़ी कमी आई
  • P50 latency लगभग 1ms कम हुई, P90 में कई tens of ms की कमी आई, और P99.5 में latency hundreds of ms से घटकर tens of ms हुई, यानी अधिकतम 90% सुधार

• operations सरल और resource efficiency बेहतर

  • Service mesh data plane के भीतर rate limiting को centralize करके infrastructure सरल हुआ
  • Quota enforcement के लिए अलग data store या caching layer की आवश्यकता नहीं रही
  • पहले rate limiting के लिए समर्पित कई Redis instances हटाए गए, जिससे meaningful compute efficiency मिली

• reliability में सुधार और incident response

  • Deployment के बाद GRL ने spikes, failovers और retry storms के दौरान बार-बार overload को रोका
  • Service mesh में excess traffic को probabilistically shed करके अचानक आने वाले load surge में भी consistent response time बनाए रखा गया
  • एक core service ने 22K से 367K RPS तक 15x traffic surge बिना degradation के झेला
  • DDoS attacks को internal systems तक पहुँचने से पहले absorb कर लिया गया
  • Incident response के दौरान production engineering team, GRL के जरिए specific high-traffic callers/procedures पर targeted rate limits लागू कर सकती है, और control plane updates हर सेकंड propagate होकर कुछ सेकंड में overload response संभव बनाते हैं
  • Service redeploy किए बिना specific traffic patterns को तेज़ी और सुरक्षित तरीके से throttle किया जा सकता है
  • कुल scale: लगभग 80 million requests per second, और 1,100 से अधिक services पर dynamic quotas लागू

rate limiting automation: Rate Limit Configurator (RLC)

• manual configuration की सीमाएँ

  • GRL ने enforcement को तो unify किया, लेकिन limit configuration अब भी manual work थी
  • Service owners YAML files में caller-wise और procedure-wise quotas define करते थे और traffic pattern बदलने पर उन्हें adjust करते थे
  • सैकड़ों microservices वाले लगातार विकसित होते environment में static settings जल्दी outdated हो जाती थीं
    • बहुत सख्त होने पर normal traffic peak पर भी throttling होती
    • बहुत ढीली होने पर actual capacity की तुलना में limits इतनी ऊँची हो जातीं कि protection का असर कम हो जाता
    • Changes dashboard analysis और manual tuning पर निर्भर थे

• RLC कैसे काम करता है

  • RLC (Rate Limit Configurator), GRL configuration को अपने-आप up to date रखता है
  • Fixed schedule पर या configuration बदलते hi तुरंत अगला cycle चलाता है:
    • Uber के observability platform से पिछले कुछ हफ्तों के metrics collect करना
    • Historical peaks और buffer margin का इस्तेमाल करके caller/procedure-wise safe limits calculate करना
    • Updated configuration को shared config store में लिखना
    • मौजूदा control plane के जरिए GRL में नई limits push करना
  • इस closed-loop process से limits वास्तविक traffic के साथ evolve करती हैं और manual intervention न्यूनतम हो जाता है

• scalable design

  • RLC को शुरू से ही multiple rate-limit calculation strategies सपोर्ट करने के लिए design किया गया
  • Default policy historical RPS data पर आधारित है, लेकिन नए policy types modular तरीके से जोड़े जा सकते हैं
  • Mapping और location data services जैसी systems, traffic forecasting और pre-planned capacity को दर्शाने वाले predictive models इस्तेमाल कर सकती हैं, जो past trends की बजाय future load predict करते हैं
  • पहले से तय contractual या operational agreements पर आधारित fixed quota allocation तरीका भी supported है
  • Modular interfaces के जरिए service domain के हिसाब से near-real-time traffic patterns, forecasts, या static quotas में से उपयुक्त calculation logic चुना जा सकता है

• shadow mode और validation

  • सुरक्षा के लिए limits को shadow mode में generate और monitor किया जा सकता है, बिना उन्हें लागू किए
  • Service owners production में rate limiting behavior देखकर बाद में उसे activate कर सकते हैं
  • Dedicated dashboards और alerts observed traffic तथा virtual drops को visualize करते हैं, जिससे rollout से पहले confidence मिलता है

• automation का असर

  • हजारों rate limit rules, manual editing के बिना अपने-आप update होते हैं
  • एक ही formulas और data sources के आधार पर सभी services में consistent policies बनती हैं
  • अलग-अलग policy types की वजह से teams अपने workload के लिए सही calculation logic चुन और extend कर सकती हैं
  • Shadow mode से लागू करने से पहले accuracy सुनिश्चित की जाती है

आगे की दिशा

• RLC आने के बाद भी buffer tuning का विस्तार, configuration changes के blast radius को कम करने के लिए per-region rate limits, और live traffic responsiveness बढ़ाने के लिए update frequency में वृद्धि पर काम जारी है
• Uber की throttler layer application के और क़रीब जाकर अतिरिक्त overload protection देती है
• आज GRL, Uber की multi-layer reliability stack का एक मुख्य घटक है, जो extreme load में भी platform की stability और fairness बनाए रखता है