प्रति-उपयोगकर्ता, प्रति-संगठन और प्रति-IP रेट‑लिमिटिंग पैटर्न—किस तरह हेडर्स, त्रुटि बॉडी, और रोलआउट ग्राहकों के लिए स्पष्ट होने चाहिए ताकि वे व्यवहार की भविष्यवाणी कर सकें।

रेट लिमिट और कोटा समान लगते हैं, इसलिए लोग अक्सर उन्हें एक ही समझते हैं। रेट लिमिट यह बताती है कि आप कितनी तेज़ी से API कॉल कर सकते हैं (अनुरोध प्रति सेकंड या प्रति मिनट)। कोटा यह बताती है कि आप लंबी अवधि में कितना उपयोग कर सकते हैं (प्रति दिन, प्रति माह, या बिलिंग चक्र)। दोनों सामान्य हैं, लेकिन जब नियम दिखाई नहीं देते तो वे यादृच्छिक लगते हैं।
क्लासिक शिकायत यह है: “यह कल काम कर रहा था।” उपयोग अक्सर स्थिर नहीं रहता। एक छोटी सी स्पाइक किसी को सीमा पार करवा सकती है भले ही उनका दैनिक कुल ठीक दिखे। कल्पना करें एक ग्राहक जो रोज़ एक रिपोर्ट चलाता है, लेकिन आज टाइमआउट के बाद जॉब रीट्राई हो गया और 2 मिनट में 10× अधिक कॉल हो गईं। API उन्हें ब्लॉक कर देता है, और उन्हें केवल अचानक विफलता दिखती है।
भ्रम तब और बढ़ता है जब त्रुटियाँ अस्पष्ट हों। अगर API 500 लौटाती है या सामान्य संदेश देती है, तो ग्राहक मानते हैं कि आपकी सेवा बंद है, न कि कि उन्होंने सीमा छू ली। वे तात्कालिक टिकट खोलते हैं, वर्कअराउंड बनाते हैं, या प्रदाता बदल देते हैं। यहां तक कि 429 Too Many Requests भी निराशाजनक हो सकता है अगर वह अगले कदम नहीं बताता।
ज्यादातर SaaS APIs दो कारणों से ट्रैफ़िक सीमित करते हैं:
इन लक्ष्यों को मिलाने से बुरा डिज़ाइन बनता है। एब्यूज़ कंट्रोल अक्सर per-IP या per-token होते हैं और कड़े हो सकते हैं। सामान्य उपयोग का आकार आम तौर पर per-user या per-organization होता है और उसके साथ स्पष्ट गाइडेंस होना चाहिए: कौनसी सीमा लगी, कब रिसेट होगा, और इसे फिर से न छूने के लिए क्या करें।
जब ग्राहक सीमाओं की भविष्यवाणी कर सकते हैं, वे उसके अनुसार योजना बनाते हैं। जब वे नहीं कर सकते, तो हर स्पाइक एक टूटा हुआ API जैसा लगता है।
रेट लिमिट सिर्फ थ्रॉटल नहीं हैं। वे एक सुरक्षा प्रणाली हैं। संख्याएँ चुनने से पहले यह स्पष्ट करें कि आप किस चीज़ की रक्षा कर रहे हैं, क्योंकि हर लक्ष्य अलग सीमाएँ और अलग अपेक्षाएँ लाता है।
उपलब्धता आमतौर पर पहला है। अगर कुछ क्लाइंट स्पाइक्स ट्रैफ़िक भेजकर आपके API को टाइमआउट में धकेल सकते हैं, तो सभी प्रभावित होंगे। यहां सीमाएँ सर्वरों को बर्स्ट के दौरान उत्तरदायी रखने चाहिए और अनुरोधों को जमा होने देने के बजाय जल्दी अस्वीकार कर देनी चाहिए।
लागत कई APIs के पीछे शांत चालक है। कुछ अनुरोध सस्ते होते हैं, कुछ महंगे (LLM कॉल, फ़ाइल प्रोसेसिंग, स्टोरेज लेखन, पेड थर्ड‑पार्टी लुकअप)। उदाहरण के लिए, Koder.ai जैसे प्लेटफ़ॉर्म पर, एक ही उपयोगकर्ता चैट-आधारित ऐप जनरेशन के ज़रिये कई मॉडल कॉल ट्रिगर कर सकता है। महंगे कार्यों को ट्रैक करने वाली सीमाएँ अचानक बिलों से बचा सकती हैं।
एब्यूज़ का व्यवहार वैध उच्च उपयोग से अलग दिखता है। क्रेडेंशियल स्टफिंग, टोकन अनुमान, और स्क्रैपिंग अक्सर कुछ IPs या अकाउंट्स से बहुत सारे छोटे अनुरोध के रूप में दिखते हैं। यहां आप कड़े सीमाएँ और तेज़ ब्लॉकिंग चाहते हैं।
मल्टी‑टेनेंट सिस्टम में निष्पक्षता मायने रखती है। एक शोरगुल ग्राहक बाकी सबको डाउन नहीं कर सकता। व्यवहार में, इसका मतलब अक्सर कंट्रोल्स को परतों में रखना होता है: मिनट-दर-मिनट हेल्दी रखने के लिए एक बर्स्ट गार्ड, महंगे एंडपॉइंट्स या कार्रवाइयों के लिए एक लागत गार्ड, ऑथ और संदिग्ध पैटर्न पर केंद्रित एब्यूज़ गार्ड, और एक निष्पक्षता गार्ड ताकि एक org बाकी सबको नहीं रोक सके।
एक सरल टेस्ट मदद करता है: एक एंडपॉइंट चुनें और पूछें, “अगर इस अनुरोध का ट्रैफ़िक 10× बढ़ जाए तो सबसे पहले क्या टूटेगा?” उत्तर बताता है कि किस सुरक्षा लक्ष्य को प्राथमिकता देनी है, और किस डायमेंशन (user, org, IP) को सीमा लेनी चाहिए।
ज्यादातर टीम एक सीमा के साथ शुरू करती हैं और बाद में पाती हैं कि उसने गलत लोगों को चोट पहुँचाई है। लक्ष्य यह है कि ऐसे डायमेंशन चुनें जो वास्तविक उपयोग से मेल खाएँ: कौन कॉल कर रहा है, कौन भुगतान कर रहा है, और क्या दुरुपयोग जैसा दिखता है।
SaaS में सामान्य डायमेंशन ऐसे होते हैं:
Per-user सीमाएँ टेनेंट के अंदर निष्पक्षता के लिए हैं। अगर एक व्यक्ति बड़ा एक्सपोर्ट चलाता है, तो उन्हें बाकी टीम की तुलना में धीमा महसूस होना चाहिए।
Per-org सीमाएँ बजट और क्षमता के बारे में हैं। भले ही दस उपयोगकर्ता एक साथ जॉब चलाएँ, org को उस स्तर तक स्पाइक नहीं करना चाहिए जिससे आपकी सेवा या प्राइसिंग अनुमान टूटें।
Per-IP सीमाएँ एक सुरक्षा जाल के रूप में बेहतर मानी जानी चाहिए, न कि बिलिंग उपकरण के रूप में। IP साझा हो सकते हैं (office NAT, मोबाइल कैरियर्स), इसलिए इन सीमाओं को उदार रखें और इन्हें मुख्य रूप से स्पष्ट दुरुपयोग रोकने के लिए रखें।
जब आप डायमेंशन्स मिलाते हैं, तय करें कि कई सीमाएँ लागू होने पर कौन “जीतेगा”। एक व्यावहारिक नियम है: यदि कोई भी संबंधित सीमा पार हुई है तो अनुरोध रिजेक्ट करें, और सबसे कार्रवाई योग्य कारण लौटाएँ। यदि किसी वर्कस्पेस की org कोटा ओवर है, तो उपयोगकर्ता या IP को दोष न दें।
उदाहरण: Koder.ai पर एक प्रो प्लान वाला वर्कस्पेस प्रति‑org स्थिर बिल्ड अनुरोधों की अनुमति दे सकता है, जबकि एक ही उपयोगकर्ता को एक मिनट में सैकड़ों अनुरोध भेजने से रोका जा सकता है। अगर एक पार्टनर इंटीग्रेशन एक साझा टोकन का उपयोग करता है, तो per-token सीमा उसे इंटरैक्टिव उपयोगकर्ताओं पर हावी होने से रोक सकती है।
ज्यादातर रेट‑लिमिटिंग समस्याएँ गणित की नहीं होतीं। वे उस व्यवहार को चुनने के बारे में होती हैं जो ग्राहकों के कॉल करने के तरीके से मेल खाता है, और लोड के दौरान इसे भविष्यवाणीय बनाए रखना होता है।
Token bucket एक सामान्य डिफ़ॉल्ट है क्योंकि यह अल्पकालिक बर्स्ट की अनुमति देता है जबकि दीर्घकालिक औसत लागू करता है। एक उपयोगकर्ता जो डैशबोर्ड रिफ्रेश करता है वह 10 तेज़ अनुरोध ट्रिगर कर सकता है। Token bucket तब अनुमति देता है अगर उनके पास टोकन सेव हैं, फिर धीरे‑धीरे उन्हें सीमित कर देता है।
Leaky bucket कड़ा है। यह ट्रैफ़िक को एक स्थिर आउटफ़्लो में समतल करता है, जो तब मदद करता है जब आपका बैकएंड स्पाइक्स सहन नहीं कर सकता (उदाहरण: महंगा रिपोर्ट जनरेशन)। ट्रेड‑ऑफ यह है कि ग्राहक इसे पहले महसूस करेंगे, क्योंकि बर्स्ट कतारबद्ध या अस्वीकार में बदल सकते हैं।
Window‑based काउंटर सरल हैं, पर डिटेल्स मायने रखते हैं। फिक्स्ड विंडो सीमाओं पर तेज़ किनारे बनाती है (एक उपयोगकर्ता 12:00:59 पर बर्स्ट कर सकता है और 12:01:00 पर फिर से)। स्लाइडिंग विंडो ज्यादा फ़ेयर लगती है और बाउंडरी स्पाइक्स घटाती है, पर इसे ज़्यादा राज्य या बेहतर डेटा स्ट्रक्चर चाहिए।
एक अलग श्रेणी है concurrency (in‑flight requests)। यह धीमे क्लाइंट कनेक्शनों और लंबी‑रनिंग एंडपॉइंट्स से आपको बचाता है। एक ग्राहक 60 अनुरोध/मिनट के भीतर रह सकता है पर फिर भी 200 अनुरोध एक साथ खोलकर आपको ओवरलोड कर सकता है।
वास्तविक सिस्टम्स में टीमें अक्सर छोटे सेट कंट्रोल्स संयोजन करती हैं: सामान्य अनुरोध दर के लिए token bucket, धीमे या भारी एंडपॉइंट्स के लिए concurrency कैप, और एंडपॉइंट समूहों के लिए अलग‑अलग बजट (सस्ते reads बनाम महंगे exports)। यदि आप केवल अनुरोध गणना से सीमित करते हैं, तो एक महंगा एंडपॉइंट सब कुछ काढ़ कर API को यादृच्छिक रूप से टूटा हुआ बना सकता है।
अच्छी कोटा निष्पक्ष और पूर्वानुमेय लगती हैं। ग्राहकों को नियम केवल ब्लॉक होने के बाद खोजने नहीं चाहिए।
अलगाव स्पष्ट रखें:
कई SaaS टीमें दोनों का उपयोग करती हैं: बर्स्ट रोकने के लिए एक छोटा रेट लिमिट और प्राइसिंग से जुड़ा एक मासिक कोटा।
Hard vs soft limits मुख्यतः सपोर्ट का निर्णय है। हार्ड लिमिट तुरंत ब्लॉक कर देता है। सॉफ्ट लिमिट पहले चेतावनी देता है, फिर बाद में ब्लॉक करता है। सॉफ्ट लिमिट गुस्से भरे टिकट कम करते हैं क्योंकि लोगों को एक बग ठीक करने या अपग्रेड करने का मौका मिलता है।
जब कोई ओवर हो जाए, व्यवहार उस रक्षा लक्ष्य से मेल खाना चाहिए। यदि ओवरयूज़ दूसरों को नुकसान पहुँचा सकता है या लागत फ़ट से बढ़ सकती है तो ब्लॉक करना उपयुक्त है। धीमा करना (स्लो प्रोसेसिंग या कम प्राथमिकता) तब ठीक है जब आप चीज़ें चलती रखना चाहें। “बाद में बिल करें” तब काम कर सकता है जब उपयोग पूर्वानुमेय हो और आपका बिलिंग फ्लो पहले से मौजूद हो।
टियर‑आधारित सीमाएँ तब सबसे अच्छी काम करती हैं जब हर टियर का expected usage shape स्पष्ट हो। एक फ्री टियर छोटे मासिक कोटा और कम बर्स्ट रेट दे सकता है, जबकि बिज़नेस और एंटरप्राइज़ टियर्स बड़े कोटा और उच्च बर्स्ट लिमिट देंगे ताकि बैकग्राउंड जॉब्स जल्दी पूरा हो सकें। यह Koder.ai के free, pro, business, और enterprise टियर्स की तरह है जो अलग‑अलग अपेक्षाएँ सेट करते हैं कि कितनी चीज़ें आप कर सकते हैं।
कस्टम सीमाएँ जल्दी सपोर्ट करना फायदेमंद है, खासकर एंटरप्राइज़ के लिए। एक साफ़ तरीका है “प्लान द्वारा डिफ़ॉल्ट, ग्राहक द्वारा ओवरराइड।” प्रत्येक org के लिए (और कभी‑कभी प्रत्येक एंडपॉइंट) एक admin-set ओवरराइड स्टोर करें और सुनिश्चित करें कि यह प्लान बदलावों के दौरान भी सुरक्षित रहे। यह भी तय करें कि कौन अनुरोध कर सकता है और यह कितनी जल्दी प्रभावी होगा।
उदाहरण: एक ग्राहक महीने के आख़िरी दिन 50,000 रिकॉर्ड इम्पोर्ट करता है। यदि उनका मासिक कोटा लगभग खत्म है, तो 80–90% पर सॉफ्ट चेतावनी उन्हें रोकने का समय देती है। एक छोटा per-second रेट लिमिट इम्पोर्ट को API पर बाढ़ मारने से रोकता है। एक मंजूर org ओवरराइड (अस्थायी या स्थायी) व्यापार को चलते रहने देता है।
सबसे पहले लिखकर तय करें कि आप क्या गिनेंगे और वह किसका है। अधिकांश टीमें तीन identities के साथ खत्म होती हैं: साइन‑इन किया हुआ उपयोगकर्ता, ग्राहक org (या workspace), और क्लाइंट IP।
एक व्यावहारिक योजना:
जब आप सीमाएँ सेट करें, तो टियर और एंडपॉइंट समूहों में सोचें, न कि एक वैश्विक संख्या पर। एक आम विफलता यह है कि कई ऐप सर्वरों में in‑memory काउंटर पर निर्भर रहना। काउंटर अलग‑अलग होंगे, और उपयोगकर्ता “यादृच्छिक” 429s देखेंगे। Redis जैसा साझा स्टोर सीमाओं को इंस्टेंसेस में स्थिर रखता है, और TTLs डेटा को छोटा रखते हैं।
रोलआउट मायने रखता है। पहले “report only” मोड से शुरू करें (क्या ब्लॉक होता इसकी लॉगिंग), फिर एक एंडपॉइंट समूह लागू करें, और बाद में विस्तारित करें। इसी तरह आप सपोर्ट टिकटों की दीवार से बचते हैं।
जब कोई ग्राहक सीमा छूता है, सबसे बुरा परिणाम उलझन है: “क्या आपका API डाउन है, या मैंने कुछ गलत किया?” स्पष्ट, सुसंगत प्रतिक्रियाएँ सपोर्ट टिकट कम करती हैं और लोगों को क्लाइंट व्यवहार ठीक करने में मदद करती हैं।
जब आप सक्रिय रूप से कॉल ब्लॉक कर रहे हों तो HTTP 429 Too Many Requests का उपयोग करें। प्रतिक्रिया बॉडी को पूर्वानुमेय रखें ताकि SDKs और डैशबोर्ड इसे पढ़ सकें।
यहाँ एक सरल JSON आकार है जो per-user, per-org, और per-IP सीमाओं पर अच्छा काम करता है:
{
"error": {
"code": "rate_limit_exceeded",
"message": "Rate limit exceeded for org. Try again later.",
"limit_scope": "org",
"reset_at": "2026-01-17T12:34:56Z",
"request_id": "req_01H..."
}
}
हेडर्स मौजूदा विंडो और क्लाइंट अगले कदम क्या कर सकता है यह समझाना चाहिए। अगर आप केवल कुछ जोड़ना चाहते हैं, तो यहाँ से शुरू करें: RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, Retry-After, और X-Request-Id।
उदाहरण: किसी ग्राहक की क्रोन जॉब हर मिनट चलती है और अचानक फेल होने लगती है। 429 के साथ RateLimit-Remaining: 0 और Retry-After: 20 होने पर वे तुरंत जान लेते हैं कि यह आउटेज नहीं है, और वे 20 सेकंड के लिए retries को देरी कर सकते हैं। यदि वे X-Request-Id सपोर्ट को साझा करते हैं, तो आप जल्दी से इवेंट ढूँढ सकते हैं।
एक और बात: सफल अनुरोधों पर भी वही हेडर्स लौटाएँ। ग्राहक सीमा के पास आने से पहले देख सकें।
अच्छे क्लाइंट सीमाओं को न्यायसंगत बनाते हैं। बुरे क्लाइंट अस्थायी सीमा को आउटेज में बदल देते हैं क्योंकि वे और ज़ोर से hammer करते हैं।
जब आपको 429 मिले, इसे धीमा होने का संकेत समझें। अगर प्रतिक्रिया बताती है कि कब फिर कोशिश करें (उदा., Retry-After), तो कम से कम उतनी देर इंतजार करें। यदि नहीं बताती, तो exponential backoff और jitter (बेतरतीबपन) का उपयोग करें ताकि हजारों क्लाइंट एक ही समय पर retry न करें।
रिट्राइज़्स को बाउंड करें: प्रयासों के बीच देरी पर कैप रखें (उदा., 30–60 सेकंड) और कुल retry समय पर सीमा (उदा., 2 मिनट के बाद बंद कर दें और त्रुटि दिखाएँ)। साथ ही इवेंट को लॉग करें ताकि डेवलपर बाद में ट्यून कर सकें।
हर चीज़ को retry न करें। कई त्रुटियाँ बिना बदलाव के सफल नहीं होंगी: 400 validation त्रुटियाँ, 401/403 ऑथ त्रुटियाँ, 404 नॉट फाउंड, और 409 कॉन्फ्लिक्ट्स जो वास्तविक बिजनेस नियम दर्शाते हैं।
राइट्स पर retries जोखिमभरे होते हैं (create, charge, send email)। अगर टाइमआउट हुआ और क्लाइंट retry करता है तो आप duplicate बना सकते हैं। idempotency keys का उपयोग करें: क्लाइंट हर लॉजिकल एक्शन के लिए एक यूनिक की भेजे, और सर्वर उसी की के रिपीट पर वही परिणाम लौटाए।
अच्छे SDKs यह आसान बना सकते हैं: status (429), कितना इंतजार करना है, क्या अनुरोध सुरक्षित रूप से retry करने योग्य है, और एक संदेश जैसे “Rate limit exceeded for org. Retry after 8s or reduce concurrency.”
ज़्यादातर सपोर्ट टिकट सीमाओं के बारे में नहीं होते; वे आश्चर्य के बारे में होते हैं। अगर उपयोगकर्ता यह अनुमान नहीं लगा सकते कि आगे क्या होगा, वे मान लेते हैं कि API टूटी हुई या अन्यायपूर्ण है।
केवल IP‑आधारित सीमाएँ उपयोग करने में अक्सर गलती होती है। कई टीमें एक सार्वजनिक IP के पीछे होती हैं (office Wi‑Fi, mobile carriers, cloud NAT)। यदि आप IP पर कैप लगाते हैं, तो एक व्यस्त ग्राहक एक ही नेटवर्क पर सबको ब्लॉक कर सकता है। per-user और per-org सीमाएँ प्राथमिक रखें, और per-IP को केवल एब्यूज़ के लिए बैकस्टॉप मानें।
एक और समस्या यह है कि सभी एंडपॉइंट्स को बराबर मानना। एक सस्ता GET और एक भारी एक्सपोर्ट जॉब को एक ही बजट साझा नहीं करना चाहिए। अन्यथा ग्राहक सामान्य ब्राउज़िंग करते‑करते अपनी अनुमति खत्म कर देंगे, और जब वे असली टास्क आज़मायेंगे तो ब्लॉक हो जाएंगे। एंडपॉइंट समूहों द्वारा अलग बाल्केट रखें या अनुरोधों को लागत के हिसाब से वज़न दें।
रीसेटिंग का समय भी स्पष्ट होना चाहिए। "रोज़ाना रिसेट होता है" काफी नहीं है। किस टाइमज़ोन में? रोलिंग विंडो या मिडनाइट रिसेट? यदि आप कैलेंडर रिसेट करते हैं तो टाइमज़ोन बताएं। यदि रोलिंग विंडो है तो विंडो लंबाई बताएं।
अंत में, अस्पष्ट त्रुटियाँ अफरा‑तफरी बनाती हैं। 500 या सामान्य JSON लौटाने से लोग और ज़ोर से retry करते हैं। 429 का उपयोग करें और RateLimit हेडर्स शामिल करें ताकि क्लाइंट बुद्धिमानी से बैक ऑफ कर सकें।
उदाहरण: अगर किसी टीम ने Koder.ai के साथ साझा कॉर्पोरेट नेटवर्क से इंटीग्रेशन बनाया, तो केवल IP‑कॅप उनकी पूरी कंपनी को ब्लॉक कर सकता है और यादृच्छिक आउटेज जैसा दिख सकता है। स्पष्ट डायमेंशन्स और स्पष्ट 429 प्रतिक्रियाएँ इसे रोकती हैं।
सभी के लिए सीमाएँ चालू करने से पहले, पूर्वानुमेयता पर ध्यान देने वाला अंतिम पास करें:
Retry-After और RateLimit हेडर्स (Limit, Remaining, Reset) शामिल करें। JSON बॉडी में एक छोटा संदेश, कौनसी सीमा लगी, और कब retry करें यह डालें।एक सहज जाँच: अगर आपका प्रोडक्ट Free, Pro, Business, और Enterprise जैसा टियर रखता है (जैसे Koder.ai), तो आप सामान्य भाषा में बता सकें कि एक सामान्य ग्राहक प्रति मिनट और प्रति दिन क्या कर सकता है, और किन एंडपॉइंट्स को अलग तरह से ट्रीट किया जाता है।
यदि आप 429 को स्पष्ट रूप से समझा नहीं सकते, तो ग्राहक मानेंगे कि API टूटी हुई है, न कि सेवा की रक्षा हो रही है।
एक B2B SaaS का चित्र बनाइए जहाँ लोग एक वर्कस्पेस (org) के अंदर काम करते हैं। कुछ पावर उपयोगकर्ता भारी एक्सपोर्ट करते हैं, और कई कर्मचारी एक साझा ऑफिस IP के पीछे बैठे हैं। यदि आप केवल IP से लिमिट लगाते हैं, आप पूरी कंपनियों को ब्लॉक कर देंगे। यदि केवल user से सीमित करते हैं, तो एक स्क्रिप्ट अभी भी पूरे वर्कस्पेस को नुकसान पहुँचा सकती है।
एक व्यावहारिक मिश्रण यह है:
जब कोई सीमा छूता है, आपका संदेश उन्हें बताना चाहिए कि क्या हुआ, अगले क्या करना है, और कब फिर से कोशिश करें। सपोर्ट को यह वाक्य कहने में सक्षम होना चाहिए:
“Request rate exceeded for workspace ACME. You can retry after 23 seconds. If you are running an export, reduce concurrency to 2 or schedule it off-peak. If this blocks normal use, reply with your workspace ID and timestamp and we can review your quota.”
उस संदेश को Retry-After और सुसंगत RateLimit हेडर्स के साथ जोड़ें ताकि ग्राहक अनुमान न लगाएँ।
एक ऐसा रोलआउट जो आश्चर्य से बचाए: पहले observe-only, फिर warn (हेडर्स और सॉफ्ट चेतावनियाँ), फिर enforce (स्पष्ट retry timing के साथ 429s), फिर thresholds को ट्यून करें प्रति‑टियर, और बड़े लॉन्च और ग्राहक ऑनबोर्डिंग के बाद समीक्षा करें।
यदि आप इन विचारों को काम करने वाले कोड में जल्दी बदलना चाहते हैं, तो Koder.ai (koder.ai) जैसा vibe‑coding प्लेटफ़ॉर्म आपकी मदद कर सकता है एक छोटा रेट लिमिट स्पेक ड्राफ्ट करने और Go मिडलवेयर जेनरेट करने में जो इसे सर्विसेज़ में सुसंगत रूप से लागू करे।
एक रेट लिमिट यह सीमित करता है कि आप कितनी तेज़ी से अनुरोध कर सकते हैं, जैसे अनुरोध प्रति सेकंड या प्रति मिनट। एक कोटा यह सीमित करता है कि आप एक लंबी अवधि में कितना उपयोग कर सकते हैं, जैसे प्रति दिन, प्रति माह, या बिलिंग चक्र।
अगर आप "यह कल काम कर रहा था" जैसी आश्चर्यजनक स्थितियाँ कम चाहते हैं, तो दोनों को स्पष्ट दिखाएँ और रिसेट समय बताएं ताकि ग्राहक व्यवहार की भविष्यवाणी कर सकें।
उस विफलता से शुरू करें जिसे आप रोकना चाहते हैं। यदि बर्स्ट से टाइमआउट होते हैं, तो आपको छोटा-समय का बर्स्ट नियंत्रण चाहिए; यदि कुछ एंडपॉइंट खर्च बढ़ाते हैं, तो आपको लागत-आधारित बजट चाहिए; और यदि ब्रूट फोर्स या स्क्रैपिंग दिख रही है तो कड़क एब्यूज़ कंट्रोल चाहिए।
एक तेज़ तरीका: पूछें “अगर इस एंडपॉइंट पर ट्रैफ़िक 10× बढ़े तो सबसे पहले क्या टूटेगा: लेटेंसी, लागत, या सुरक्षा?” फिर उसी के अनुसार सीमा डिज़ाइन करें।
Per-user सीमाएँ एक व्यक्ति को उनकी टीम के बाकी लोगों को धीमा करने से रोकती हैं, और per-org सीमाएँ एक वर्कस्पेस को एक अनुमानित सीमा के भीतर रखती हैं जो प्राइसिंग और क्षमता से मेल खाती है। जब कोई साझा इंटीग्रेशन की (shared integration key) हो, तब per-token सीमाएँ जोड़ें ताकि इंटरैक्टिव उपयोगकर्ताओं पर असर न पड़े।
Per-IP सीमाएँ केवल एब्यूज़ के लिए बैकअप के रूप में समझें, क्योंकि साझा नेटवर्क पर IP-आधारित सीमा निर्दोष उपयोगकर्ताओं को ब्लॉक कर सकती है।
Token bucket सामान्य रूप से अच्छा डिफ़ॉल्ट है जब आप अल्पकालिक बर्स्ट की अनुमति देना चाहते हैं पर दीर्घकालिक औसत लागू रखना चाहते हैं। यह डैशबोर्ड रिफ्रेश जैसी UX पैटर्न के लिए फायदेमंद है जो एक साथ कई अनुरोध फायर करते हैं।
यदि आपका बैकएंड किसी भी स्पाइक को बर्दाश्त नहीं कर सकता, तो leaky bucket या स्पष्ट कतार (queuing) अधिक सुसंगत लगेगा, पर वह बर्स्ट के समय कम सहनशील होगा।
जब नुकसान इन-फ्लाइट अनुरोधों से है न कि कुल अनुरोध संख्या से, तब concurrency सीमा जोड़ें। यह धीमे एंडपॉइंट्स, लंबा पोलिंग, स्ट्रीमिंग, बड़े एक्सपोर्ट्स, या खराब नेटवर्क कंडीशन्स वाले क्लाइंट्स के साथ सामान्य है।
Concurrency कैप एक ग्राहक को “60 अनुरोध/मिनट के भीतर रहकर” सैकड़ों खुले कनेक्शनों से सिस्टम बांधने से रोकता है।
जब आप सक्रिय रूप से थ्रॉटल कर रहे हैं तो HTTP 429 लौटाएँ, और एक स्पष्ट त्रुटि बॉडी दें जो बताए किस स्कोप पर सीमा लगी (user, org, IP, या token) और कब फिर से कोशिश कर सकते हैं। सबसे सहायक हेडर Retry-After है, क्योंकि यह क्लाइंट्स को ठीक-ठीक बताता है कि कितनी देर रुकना है।
सफल अनुरोधों पर भी rate limit हेडर्स लौटाएँ ताकि ग्राहक देख सकें कि वे सीमा के पास हैं।
सरल डिफ़ॉल्ट: अगर Retry-After मौजूद है, तो कम से कम उतनी देर इंतजार करें। यदि नहीं है, तो exponential backoff के साथ थोड़ी randomness (jitter) डालें ताकि हजारों क्लाइंट एक ही समय पर फिर से न आज़माएँ।
रिट्राइज़ सीमित रखें, और उन त्रुटियों को फिर से आज़माएँ मत जो बदलाव के बिना सफल नहीं हों, खासकर auth और validation गलतियाँ।
जब ओवरयूज़ दूसरों को नुकसान पहुँचा सकता है या लागत अचानक बढ़ सकती है तो hard limits उपयोगी हैं। जब आप पहले चेतावनी देना और एक मौका देना चाहते हैं (उदाहरण: बग ठीक करने या अपग्रेड करने के लिए), तो soft limits बेहतर हैं।
व्यावहारिक पैटर्न: 80–90% पर चेतावनी दें, और बाद में लागू करें—इससे सपोर्ट टिकट कम होंगे और रनअवे उपयोग रोका जा सकेगा।
IP-आधारित सीमाएँ उदार रखें और मुख्य रूप से एब्यूज़ पैटर्न के लिए रखें, क्योंकि कई कंपनियाँ NAT, ऑफिस वाई‑फाई, या मोबाइल कैरियर के पीछे एक सार्वजनिक IP साझा करती हैं। यदि आप कड़ी per-IP सीमा लगाते हैं तो एक स्क्रिप्ट पूरे ग्राहक को ब्लॉक कर सकती है।
सामान्य उपयोग के लिए per-user और per-org सीमाएँ प्राथमिक रखें; per-IP को सिर्फ बैकस्टॉप की तरह रखें।
नए सीमाएँ लागू करते समय चरणबद्ध रूप से रोलआउट करें ताकि प्रभाव पहले दिखे और उपयोगकर्ता दर्द महसूस न करें। पहले “report only” लॉगिंग से शुरू करें ताकि आप देख सकें क्या ब्लॉक होता, फिर कुछ एंडपॉइंट्स या कुछ टेनेंट्स पर लागू करें, और तभी विस्तार करें।
429s में spike, limiter से जोड़ा लेटेंसी, और सबसे ज़्यादा ब्लॉक हो रहे identities पर नज़र रखें—ये संकेत बताते हैं कि थ्रेशहोल्ड या डायमेंशन गलत हैं।