सार्वजनिक APIs के लिए रेट‑लिमिटिंग: व्यावहारिक कोटे और लॉकआउट फ्लो

असल में रेट‑लिमिटिंग किस समस्या को हल करती है

सार्वजनिक APIs के लिए रेट‑लिमिटिंग का मकसद यूज़र्स को दंडित करना नहीं है। यह एक सेफ़्टी‑वाल्व है जो आपके सर्विस को उपलब्ध रखता है जब ट्रैफ़िक अजीब हो जाता है — चाहे वह अजीब व्यवहार हमलावर की वजह से हो या किसी क्लाइंट बग की वजह से।

"दुरुपयोग" अक्सर शुरुआत में सामान्य लगता है: हर एन्डपॉइंट को चलाने वाला एक स्क्रेपर, ब्रूट‑फोर्स लॉगिन प्रयास, ऑथ रूट्स पर टोकन‑स्टफिंग, या एक रनअवे क्लाइंट जो टाइमआउट के बाद कड़ी लूप में एक ही रिक्वेस्ट बार‑बार भेजे। कई बार कोई खास हमला भी नहीं होता — एक मोबाइल ऐप अपडेट में खराब कैशिंग नियम निकल गया और अचानक हर डिवाइस आपकी API को हर सेकंड पोल करने लगा।

काम सीधा है: अपटाइम और लागत की रक्षा करें बिना असली यूज़र्स को ब्लॉक किए। अगर आपका बैकएंड मीटर किया जाता है (compute, database, email/SMS, AI कॉल्स), तो एक शोर करने वाला अभिनेता तेज़ी से बड़े बिल में बदल सकता है।

सिर्फ रेट‑लिमिटिंग अकेले काफी नहीं है। बिना मॉनिटरिंग और स्पष्ट त्रुटि प्रतिक्रियाओं के आपको साइलेंट फेलियर्स, भ्रमित ग्राहक और "आपकी API डाउन है" जैसे सपोर्ट टिकट मिलेंगे जबकि असल में सिस्टम थ्रॉटल कर रहा होगा।

एक पूरा गार्डरेल आमतौर पर कई अलग‑अलग हिस्सों में होता है:

• Rate limits: शॉर्ट‑विंडो कैप्स (प्रति सेकंड/मिनट) जो स्पाइक्स को रोकते हैं।
• Quotas: लंबी‑विंडो अलाउंस (प्रति दिन/महीना) जो उपयोग को पूर्वानुमानयोग्य बनाते हैं।
• Lockouts: स्पष्ट दुरुपयोग पैटर्न के लिए अस्थायी ब्लॉक्स।
• Exceptions: ट्रस्टेड इंटीग्रेशन, इंटरनल टूल या VIP ग्राहकों के लिए allowlists।

यदि आप AppMaster जैसे प्लेटफ़ॉर्म पर API बैकेंड बना रहे हैं, तो यह नियम अभी भी मायने रखते हैं। भले ही कोड क्लीन और रे‑जनरेटेड हो, आपको डिफ़ॉल्ट सुरक्षा चाहिए ताकि एक खराब क्लाइंट आपकी पूरी सर्विस को नीचे न ले जाए।

प्रमुख शब्द: रेट‑लिमिट्स, कोटा, थ्रॉटलिंग और लॉकआउट

ये शब्द अक्सर एक साथ मिल जाते हैं, लेकिन वे अलग‑अलग समस्याएँ हल करते हैं और यूज़र्स के लिए अलग अनुभव होते हैं।

रेट‑लिमिट, कोटा और समकालिकता: हर एक का मतलब

एक rate limit एक स्पीड‑लिमिट है: एक छोटे विंडो में एक क्लाइंट कितनी रिक्वेस्ट कर सकता है (प्रति सेकंड, प्रति मिनट)। एक quota एक बजट है: लंबे समय में कुल उपयोग (प्रति दिन, प्रति महीना)। एक concurrency limit यह तय करता है कि एक साथ कितनी रिक्वेस्ट्स प्रोसेस में हो सकती हैं — यह महँगे एंडपॉइंट्स के लिए उपयोगी है भले ही रिक्वेस्ट‑रेट सामान्य लगे।

किस जगह पर यह लिमिट जोड़ते हैं, यह मायने रखता है:

• Per IP: सरल, पर साझा नेटवर्क्स (ऑफिस, स्कूल, मोबाइल कैरियर्स) को दंडित करता है।
• Per user: लॉग‑इन एप के लिये बढ़िया, पर भरोसेमंद पहचान पर निर्भर करता है।
• Per API key: सार्वजनिक APIs के लिए आम, स्पष्ट मालिकाना और संदेश भेजने में आसान।
• Per endpoint: तब उपयोगी जब एक रूट बाकी की तुलना में बहुत भारी हो।

थ्रॉटलिंग बनाम ब्लॉकिंग, और लॉकआउट कहां आता है

Soft throttling क्लाइंट को धीमा कर देता है (डिले, कम बर्स्ट कैपैसिटी) ताकि वे बिना टूटे रिकवर कर सकें। Hard blocking रिक्वेस्ट्स को तुरंत रिजेक्ट कर देता है, आमतौर पर HTTP 429 के साथ।

एक lockout सामान्य 429 से मजबूत होता है। 429 कहता है "जल्दी कोशिश करें।" एक लॉकआउट कहता है "जब तक कोई शर्त पूरी नहीं होती तब तक रोकें," जैसे कूल‑डाउन अवधि, मैन्युअल समीक्षा, या की रीसेट। लॉकआउट्स को स्पष्ट दुरुपयोग संकेतों (क्रेडेंशियल स्टफिंग, आक्रामक स्क्रैपिंग, बार‑बार गलत ऑथ) के लिए सुरक्षित रखें, न कि सामान्य ट्रैफ़िक स्पाइक्स के लिए।

यदि आप AppMaster जैसे टूल से API बना रहे हैं, तो इन्हें अलग‑अलग कंट्रोल्स की तरह देखें: बर्स्ट के लिये शॉर्ट‑विंडो सीमाएँ, लागत के लिये लंबे‑विंडो कोटा, और केवल बार‑बार बुरा व्यवहार दिखने पर लॉकआउट।

अटकलें लगाए बिना व्यावहारिक सीमाएँ चुनना

अच्छी सीमाएँ एक लक्ष्य से शुरू होती हैं: बैकएंड की रक्षा करें जबकि सामान्य उपयोगकर्ता अपना काम पूरा कर पाएँ। पहले दिन परदम फिट नंबर की ज़रूरत नहीं है। ज़रूरी है एक सुरक्षित बेसलाइन और उसे एडजस्ट करने का तरीका।

एक सरल शुरुआती बिंदु प्रति‑API‑की सीमा है जो आपके API के प्रकार से मेल खाती हो:

• कम ट्रैफ़िक: 60–300 रिक्वेस्ट्स प्रति मिनट प्रति की
• मध्यम ट्रैफ़िक: 600–1,500 रिक्वेस्ट्स प्रति मिनट प्रति की
• उच्च ट्रैफ़िक: 3,000–10,000 रिक्वेस्ट्स प्रति मिनट प्रति की

फिर एंडपॉइंट प्रकार के हिसाब से सीमाएँ विभाजित करें। पढ़ना (reads) आमतौर पर सस्ता होता है और अधिक लिमिट ले सकता है। लिखना (writes) डेटा बदलता है, अक्सर अतिरिक्त लॉजिक ट्रिगर करता है, और कड़ाई से कैप किया जाना चाहिए। सामान्य पैटर्न: GET रूट्स के लिये ~1,000/मिनट पर विचार करें पर POST/PUT/DELETE के लिये 100–300/मिनट।

महँगे एंडपॉइंट्स की पहचान करें और उन्हें अलग व्यवहार दें। सर्च, रिपोर्ट जेनेरेशन, एक्सपोर्ट्स, फ़ाइल अपलोड्स और जो भी कई टेबल्स को हिट करते हैं या भारी बिजनेस लॉजिक चलाते हैं उन्हें छोटा बकेट दें यहाँ तक कि अगर बाकी API उदार हो भी। अगर आपका बैकएंड विजुअल वर्कफ़्लो (उदाहरण के लिये Business Process flows) उपयोग करता है, तो हर एडेड स्टेप वास्तविक काम है जो लोड के साथ गुणा हो जाता है।

बर्स्ट्स के लिये दो विंडो के लिये योजना बनाएं: एक छोटा विंडो तेज़ स्पाइक्स को अवशोषित करे, और एक लंबा विंडो सतत उपयोग को नियंत्रित रखे। एक आम संयोजन 10 सेकंड प्लस 10 मिनट है। यह तेज़‑क्लिक करने वाले असली उपयोगकर्ताओं को मदद करता है, बिना स्क्रेपर को असीमित स्पीड देने के।

अंत में, तय करें कि क्लाइंट सीमा पार करने पर क्या होता है। अधिकांश सार्वजनिक APIs HTTP 429 लौटाते हैं और स्पष्ट retry समय भेजते हैं। अगर काम देर से किया जा सकता है (जैसे एक्सपोर्ट), तो हार्ड‑ब्लॉक करने के बजाय उसे कतारबद्ध करने पर विचार करें ताकि असली उपयोगकर्ता अभी भी परिणाम पाएं।

ऐसा प्रति‑कुंजी कोटा डिजाइन करना जो निष्पक्ष लगे

प्रति‑कुंजी कोटा अक्सर सबसे निष्पक्ष होता है क्योंकि यह ग्राहकों के वास्तविक उपयोग से मेल खाता है: एक अकाउंट, एक API की, स्पष्ट ज़िम्मेदारी। IP‑आधारित सीमाएँ अभी भी उपयोगी हैं, पर वे अक्सर निर्दोष उपयोगकर्ताओं को दंडित करती हैं।

साझा IP सबसे बड़ा कारण है। पूरा ऑफिस एक सार्वजनिक IP से बाहर जा सकता है, और मोबाइल कैरियर्स हजारों डिवाइसों को छोटे IP पूल के पीछे रख सकते हैं। अगर आप केवल प्रति‑IP कैप पर निर्भर करते हैं, तो एक शोर करने वाला उपयोगकर्ता सभी को धीमा कर सकता है। प्रति‑कुंजी कोटा इस समस्या से बचाता है, और आप स्पष्ट बाढ़ के लिये एक हल्का प्रति‑IP बैकस्टॉप रख सकते हैं।

कोटा निष्पक्ष लगे इसके लिये उन्हें ग्राहक टियर से बांधें बिना नए उपयोगकर्ताओं को फंसाए। फ्री या ट्रायल की असली परीक्षण के लिये काम करे, पर ऐसी स्केल पर नहीं जो आपको नुकसान पहुंचाए। सरल पैटर्न: उदार बर्स्ट्स, मध्यम सतत दर, और प्लान के अनुरूप दैनिक कोटा।

एक स्थिर प्रति‑कुंजी नीति:

• छोटे बर्स्ट्स की अनुमति दें (पेज लोड, बैच इम्पोर्ट), फिर एक स्थिर दर लागू करें।
• हर की पर दैनिक कैप जोड़ें ताकि स्क्रैपिंग और रनअवे लूप सीमित हों।
• प्लान बढ़ने पर लिमिट्स बढ़ाएँ, पर वही संरचना रखें ताकि व्यवहार सुसंगत रहे।
• ताज़ी बनाई गई कुंजियों के लिये एक कम कैप रखें जब तक वे अच्छा इतिहास न बना लें।
• स्पष्ट बाढ़ पकड़ने के लिये एक छोटा प्रति‑IP लिमिट रखें।

की‑शेयरिंग और ऑटोमेटेड साइनअप्स को रोकने के लिये भारी निगरानी की ज़रूरत नहीं। सरल चेक्स से शुरू करें जैसे असामान्य भौगोलिक बदलाव, एक घंटे में बहुत‑सारे अलग IPs एक ही की के लिये, या एक ही स्रोत से कई नई कुंजियाँ बनना। पहले फ़्लैग और धीमा करें; लॉकआउट केवल बार‑बार संकेतों के बाद करें।

अनामिक ट्रैफ़िक पर कड़ी कैप्स समझदारी होती है। अगर आप ट्रायल की देते हैं, उन्हें कड़ी रेट‑लिमिट करें और सीमाएँ बढ़ाने से पहले बेसिक वेरिफिकेशन माँगें। अगर आपकी API किसी सार्वजनिक फ़ॉर्म को पावर देती है, तो अलग अनामिक एंडपॉइंट पर विचार करें जिसका अपना कोटा हो ताकि बाकी बैकएंड सुरक्षित रहे।

यदि आप AppMaster के साथ अपना API बनाते हैं, तो प्रति‑कुंजी लॉजिक को संगत रखना आसान होता है क्योंकि ऑथ, बिजनेस नियम और रिस्पॉन्स हैंडलिंग एक जगह रहते हैं।

क्लाइंट‑फ्रेंडली प्रतिक्रियाएँ और हेडर (ताकि यूज़र्स रिकवर कर सकें)

रेट‑लिमिटिंग तब ही लंबी अवधि में काम करती है जब क्लाइंट समझ सके कि क्या हुआ और अगला कदम क्या है। रिस्पॉन्स को सुस्त‑समान रखें: एक ही स्टेटस कोड, एक ही फ़ील्ड्स, हर एंडपॉइंट पर एक ही अर्थ।

जब क्लाइंट लिमिट पार कर लेता है, तो HTTP 429 (Too Many Requests) लौटाएँ और स्पष्ट संदेश व ठोस इंतज़ार समय दें। सबसे तेज़ सुधार Retry-After जोड़ना है, क्योंकि साधारण क्लाइंट भी सही तरीके से पॉज़ कर सकते हैं।

एक छोटा सेट हेडर्स लिमिट्स को स्व‑स्पष्टीकरण बनाता है। नाम सुसंगत रखें और इन्हें सफल प्रतिक्रियाओं पर भी शामिल करें (ताकि क्लाइंट स्वयं‑रेखांकन कर सकें) और 429 प्रतिक्रियाओं पर भी (ताकि क्लाइंट रिकवर कर सकें):

• Retry-After: सेकंड में पुनः प्रयास करने की समयावधि
• X-RateLimit-Limit: वर्तमान विंडो के लिये अनुमत रिक्वेस्ट्स
• X-RateLimit-Remaining: वर्तमान विंडो में बचे हुए रिक्वेस्ट्स
• X-RateLimit-Reset: कब विंडो रिसेट होगा (epoch सेकेंड या ISO समय)
• X-RateLimit-Policy: छोटी टेक्स्ट पंक्ति जैसे "60 requests per 60s"

एरर बॉडी को आपकी सक्सेस प्रतिक्रिया जितनी संरचित रखें। एक आम पैटर्न है एक एरर ऑब्जेक्ट जिसमें एक स्थिर code, एक मनुष्यों‑के लिये message, और रिकवरी सुझाव हों।

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

जब क्लाइंट 429 देखे तो उन्हें बैक‑ऑफ कैसे करें बताएं। एक्सपोनेंशियल बैकऑफ एक अच्छा डिफ़ॉल्ट है: पहले 1s, फिर 2s, फिर 4s, और इसे किसी सीमा (उदाहरण के लिये 30–60 सेकंड) पर रोक दें। साथ ही यह स्पष्ट बताएं कि कब retry करना बंद कर देना चाहिए।

कोटा के पास अचानक आश्चर्य से बचें। जब कोई की कैप के करीब हो (मान लें 80–90% उपयोग), तो एक वार्निंग फ़ील्ड या हेडर शामिल करें ताकि क्लाइंट असफल होने से पहले धीमा कर सके। यह तब और भी महत्वपूर्ण है जब एक स्क्रिप्ट कई रूट्स को तेज़ी से हिट कर सकती है और बजट जल्दी भगा सकती है।

चरण‑बद्ध: सीमाएँ और कोटा रोलआउट करने की सरल योजना

रोलआउट तब बेहतर काम करता है जब आप सीमाओं को एक प्रोडक्ट बिहेवियर की तरह देखें, न कि एक एक‑बार की फ़ायरवॉल नीति। लक्ष्य लगातार एक जैसा है: बैकएंड की रक्षा करें जबकि सामान्य ग्राहक आगे बढ़ सकें।

पहले एक त्वरित इन्वेंटरी से शुरू करें। हर एंडपॉइंट की सूची बनाएं, फिर प्रत्येक को लागत (CPU, DB, तृतीय‑पक्ष कॉल्स) और जोखिम (लॉगिन, पासवर्ड रीसैट, सर्च, फ़ाइल अपलोड) के अनुसार चिह्नित करें। इससे आप हर जगह एक ही कठोर सीमा लगाने से बचते हैं।

सामान्यतः रोलआउट क्रम जो आश्चर्य से बचाता है:

• एंडपॉइंट्स को लागत और जोखिम के हिसाब से टैग करें और तय करें किन पर कड़ाई ज़रूरी है (लॉगिन, बुल्क एक्सपोर्ट)।
• पहचान कुंजियों को प्राथमिकता के क्रम में चुनें: सबसे पहले API key, फिर user id, और IP केवल फ़ॉलबैक के रूप में।
• बर्स्ट रोकने के लिये शॉर्ट‑विंडो लिमिट (प्रति 10 सेकंड या प्रति मिनट) जोड़ें।
• सतत उपयोग को रोकने के लिये लंबे‑विंडो कोटा (प्रति घंटा या प्रति दिन) जोड़ें।
• ऑप्स के लिए allowlists जोड़ें ताकि इंटरनल टूल्स ब्लॉक न हों।

पहला रिलीज कंज़र्वेटिव रखें। बाद में ढील देना आसान है बजाय गुस्साए हुए यूज़र्स को अनब्लॉक करने के।

मॉनिटर और ट्यून करें, फिर अपनी नीति का वर्शन रखें। कितनी रिक्वेस्ट्स लिमिट पर पहुँच रही हैं, कौन से एंडपॉइंट्स ट्रिगर कर रहे हैं, और कितनी अलग‑अलग कुंजियाँ प्रभावित हो रही हैं ये ट्रैक करें। जब आप नंबर बदलें, तो इसे एक API बदलाव की तरह ट्रीट करें: दस्तावेज़ बनाएं, धीरे‑धीरे रोल आउट करें, और पुराने एवं नए नियम अलग रखें ताकि आप तेज़ी से रोलबैक कर सकें।

यदि आप AppMaster पर अपना API बना रहे हैं, तो इन नियमों को अपने एंडपॉइंट्स और बिजनेस लॉजिक के साथ-साथ प्लान करें ताकि लिमिट्स प्रत्येक वर्कफ़्लो की वास्तविक लागत से मेल खाएँ।

लॉकआउट वर्कफ़्लो जो बिना नाटक के दुरुपयोग रोकते हैं

लॉकआउट सीटबेल्ट की तरह हैं। उन्हें स्पष्ट दुरुपयोग को तेज़ी से रोकना चाहिए, पर सामान्य उपयोगकर्ताओं को भी जब कुछ गलत हो गया हो तो साफ़ रास्ता देना चाहिए।

एक शांत‑चित्त 접근 प्रोग्रेसिव पेनल्टीज़ है। मानिए क्लाइंट खराब कॉन्फ़िगर हो सकता है, दुर्भावनापूर्ण नहीं, और केवल पैटर्न दोहराने पर ही स्केल‑अप करें।

एक सरल प्रोग्रेसिव लैडर

ऐसे कदम रखिए जो बताने में आसान और लागू करने में आसान हों:

• चेतावनी: क्लाइंट को बताएं कि वे सीमा के करीब हैं और कब रिसेट होगा।
• धीमा करना: उस की के लिये शॉर्ट डिले या प्रति‑सेकंड कड़ाई बढ़ाएँ।
• अस्थायी लॉकआउट: कुछ मिनटों के लिये ब्लॉक करें और सटीक अनलॉक टाइम बताएं।
• लंबा लॉकआउट: केवल कई विंडोज़ में बार‑बार बर्स्ट के बाद।
• मैन्युअल समीक्षा: जो पैटर्न जानबूझकर या बार‑बार आ रहे हों।

यह तय करना कि किसे लॉक करना है, मायने रखता है। प्रति‑API‑कुंजी आमतौर पर सबसे निष्पक्ष होता है क्योंकि यह कॉलर को निशाना बनाता है, न कि साझा नेटवर्क के सभी लोगों को। यदि उपयोगकर्ता कुंजियाँ rotate करते हैं तो पर‑अकाउंट उपाय मदद करता है। पर‑IP अनामिक ट्रैफ़िक में मदद कर सकता है, पर NATs, ऑफिस और मोबाइल कैरियर्स के लिए फॉल्स‑पॉज़िटिव दे सकता है। गंभीर दुरुपयोग में संकेतों को जोड़ें (उदा., की लॉक और उस IP के लिये अतिरिक्त जांच), पर ब्लास्ट‑रेडियस छोटा रखें।

लॉकआउट्स को समय‑आधारित बनाएं: "14:05 UTC तक ब्लॉक" और "30 मिनट की अच्छी व्यवहार के बाद रिसेट" जैसी सरल नियमावली रखें। ऑटोमेटेड सिस्टम्स के लिये स्थायी बैन से बचें—एक बग्ड क्लाइंट तेज़ी से लिमिट जला सकता है, इसलिए पेनल्टी को समय के साथ घटने वाला रखें। कम दर की अवधि पेनल्टी स्तर को घटा देनी चाहिए।

यदि आप AppMaster में API बना रहे हैं, तो यह लैडर स्टोर्ड काउंटर और एक Business Process के साथ अच्छी तरह मेल खाता है जो allow/slow/block का फैसला करता है और की के लिये अनलॉक‑टाइम लिखता है।

दोहराने वाले अपराधियों के लिये मैन्युअल समीक्षा पथ रखें। उपयोगकर्ताओं से बहस न करें—रिक्वेस्ट IDs, टाइमस्टैम्प और API की का नाम माँगें और फिर सबूत के आधार पर निर्णय लें।

सामान्य गलतियाँ जो फॉल्स‑पॉज़िटिव बनाती हैं

फॉल्स‑पॉज़िटिव्स तब होते हैं जब आपकी डिफेन्सेस सामान्य उपयोगकर्ताओं को ब्लॉक कर देती हैं। ये आमतौर पर तब होते हैं जब नियम लोगों के असली उपयोग के तरीके के लिये बहुत सरल होते हैं।

एक क्लासिक गलती एक ग्लोबल लिमिट को हर जगह लागू करना है। अगर आप सस्ते रीड एंडपॉइंट और महँगे एक्सपोर्ट को समान मानते हैं, तो या तो आप सस्ते को अधिक सुरक्षित कर देंगे (कष्टप्रद) या महँगे को कम सुरक्षा देंगे (खतरनाक)। एंडपॉइंट लागत के हिसाब से सीमाएँ अलग रखें और भारी मार्गों को कड़ा रखें।

केवल IP‑आधारित लिमिटिंग भी एक आम फंदा है। कई असली उपयोगकर्ता एक ही सार्वजनिक IP शेयर करते हैं (ऑफिस, स्कूल, मोबाइल कैरियर्स)। एक भारी उपयोगकर्ता सभी को ब्लॉक कर सकता है और यह रैंडम आउटेज जैसा दिखता है। प्राथमिक रूप से प्रति‑API‑किजी लिमिट्स रखें, और IP को सेकंडरी सिग्नल के रूप में इस्तेमाल करें।

फेलियर्स भी फॉल्स‑पॉज़िटिव कर सकते हैं। अगर आपका लिमिटर स्टोर डाउन हो, तो "fail closed" आपकी पूरी API को नीचे ले जा सकता है। "Fail open" एक स्पाइक को आमंत्रित कर सकता है जो बैकएंड को डाउन कर दे। एक स्पष्ट फॉलबैक चुनें: एज पर एक छोटा इमरजेंसी कैप रखें, और गैर‑महत्वपूर्ण एंडपॉइंट्स पर गरैसफ़ुल дег्रेडेशन लागू करें।

क्लाइंट हैंडलिंग अधिक मायने रखती है जितना टीमें मानती हैं। अगर आप सामान्य 429 बिना स्पष्ट संदेश के लौटाते हैं, उपयोगकर्ता और ज़्यादा रीट्राय करेंगे और और ब्लॉक्स ट्रिगर होंगे। हमेशा Retry-After भेजें, और एरर टेक्स्ट को विशिष्ट रखें ("Too many requests for this key. Try again in 30 seconds.").

सबसे बचने योग्य समस्या गोपनीयता है। छुपी हुई सीमाएँ प्रोडक्शन लोड पर ग्राहकों को बग जैसी लगती हैं। एक सरल नीति साझा करें और उसे स्थिर रखें।

त्वरित चेकलिस्ट फॉल्स‑पॉज़िटिव से बचने के लिये:

• महँगे बनाम सस्ते एंडपॉइंट्स के लिये अलग‑अलग सीमाएँ
• प्राथमिक रूप से API की द्वारा लिमिट करना, केवल IP पर नहीं
• लिमिटर उपलब्ध न होने पर परिभाषित व्यवहार
• स्पष्ट 429 प्रतिक्रियाएँ और Retry-After
• सीमाएँ लागू करने से पहले दस्तावेज़ और संप्रेषण

अगर आप AppMaster से API बनाते हैं, तो अक्सर इसका मतलब एंडपॉइंट्स के अनुसार अलग‑अलग कैप सेट करना और सुसंगत एरर पेलोड लौटाना होता है ताकि क्लाइंट बिना अनुमान लगाए बैक‑ऑफ कर सके।

मॉनिटरिंग और अलर्टिंग जो वास्तव में मदद करती है

रेट‑लिमिटिंग तभी काम करती है जब आप रीयल‑टाइम में देख सकें कि क्या हो रहा है। लक्ष्य हर स्पाइक पकड़ना नहीं है, बल्कि उन पैटर्न्स को पहचानना है जो आउटेज या गुस्साए हुए यूज़र्स में बदल सकते हैं।

चुनें कुछ संकेत जो वॉल्यूम और इरादे दोनों समझाएँ:

• रिक्वेस्ट्स प्रति मिनट (कुल और प्रति API की)
• 429 दर (थ्रॉटल्ड रिक्वेस्ट्स) और 5xx दर (बैकएंड दर्द)
• बार‑बार 401/403 बर्स्ट्स (खराब कीज़, क्रेडेंशियल स्टफिंग, गलत कॉन्फ़िगर क्लाइंट)
• वॉल्यूम और लागत के हिसाब से टॉप एंडपॉइंट्स (धीमी क्वेरीज, भारी एक्सपोर्ट्स)
• टॉप 10 में नए या अनपेक्षित एंडपॉइंट्स

"खराब ट्रैफ़िक" और "हमने कुछ शिप किया" अलग करने के लिये डैशबोर्ड में संदर्भ जोड़ें: डिप्लॉय समय, फीचर‑फ्लैग बदलाव, मार्केटिंग सेंड्स। अगर ट्रैफ़िक किसी रिलीज के तुरंत बाद कूदता है और 429/5xx मिश्रण स्वास्थ्यवर्धक रहता है, तो यह आमतौर पर ग्रोथ है न कि दुरुपयोग। यदि कूद एक की, एक IP रेंज, या एक महँगे एंडपॉइंट पर केंद्रीत है, तो इसे संदिग्ध मानें।

अलर्ट्स को उबाऊ रखें। थ्रेशहोल्ड्स के साथ कूडलोड्स लगाएँ ताकि आपको हर मिनट पेज न मिले:

• 10 मिनट के लिये 429 दर X% से ऊपर हो, प्रति घंटे एक बार नोटिफाई करें
• 5 मिनट के लिये 5xx दर Y% से ऊपर हो, तुरंत पेज करें
• एक की 15 मिनट के लिये कोटा Z% से अधिक कर दे, जांच खोलें
• 401/403 बर्स्ट्स N/min से ऊपर हों, संभावित दुरुपयोग के लिये चिन्हित करें

जब अलर्ट फायर करे, एक छोटा इंसीडेंट नोट रखें: क्या बदला, आपने क्या देखा (टॉप कीज़/एन्डपॉइंट्स), और आपने क्या समायोजित किया (लिमिट्स, कैशेस, अस्थायी ब्लॉक्स)। समय के साथ वे नोट्स आपका असली प्लेबुक बन जाते हैं।

उदाहरण: आप एक नया सर्च एंडपॉइंट लॉन्च करते हैं और ट्रैफ़िक दुगना हो जाता है। अगर अधिकांश कॉल्स कई कीज़ में फैल कर उस एंडपॉइंट को हिट कर रहे हैं, तो प्रति‑कुंजी कोटा थोड़ा बढ़ाएँ और एंडपॉइंट को ऑप्टिमाइज़ करें। अगर एक की लगातार एक्सपोर्ट हिट कर रहा है और लेटेंसी बढ़ा रहा है, तो उस एंडपॉइंट को अलग कैप करें और मालिक से संपर्क करें।

लॉन्च से पहले और बाद के लिए त्वरित चेकलिस्ट

एक अच्छी सेटअप तब उबाऊ होता है जब यह काम कर रहा हो। यह चेकलिस्ट उन मुद्दों को पकड़ती है जो सामान्यतः फॉल्स‑पॉज़िटिव या स्पष्ट गैप बनाते हैं।

नया एंडपॉइंट रिलीज करने से पहले

स्टेजिंग में और लॉन्च के तुरंत बाद ये जांचें:

• पहचान: सुनिश्चित करें कि लिमिटर सही चीज़ पर किज़ करता है (सबसे पहले API key, फिर user या IP फ़ॉलबैक) और रोटेट कीज़ पुराने पेनल्टी नहीं विरासत में लेतीं।
• सीमाएँ: एक डिफ़ॉल्ट प्रति‑की कोटा सेट करें, फिर एंडपॉइंट लागत (सस्ता रीड बनाम महँगा राइट) के अनुसार समायोजन करें।
• प्रतिक्रियाएँ: स्पष्ट स्थिति और रिकवरी जानकारी लौटाएँ (रिट्राय समय, शेष बजट, स्थिर एरर कोड)।
• लॉग्स: रिकॉर्ड करें कि किसे लिमिट किया गया (की/यूज़र/IP), कौन सा रूट, कौन सा नियम फायर हुआ, और सपोर्ट के लिये एक रिक्वेस्ट ID।
• बायपास: अपने मॉनिटर और ट्रस्टेड इंटीग्रेशन के लिये एक इमरजेंसी allowlist रखें।

यदि आप AppMaster पर बना रहे हैं, तो प्रत्येक नए API एंडपॉइंट को एक कॉस्ट‑टियर निर्णय की तरह ट्रीट करें: एक साधारण लुकअप उदार हो सकता है, जबकि कोई भी चीज़ जो भारी बिजनेस लॉजिक ट्रिगर करे उसे शुरू में कड़ा रखें।

जब कोई इंसीडेंट हो (दुरुपयोग या अचानक ट्रैफ़िक)

बैकएंड की रक्षा करें जबकि असली उपयोगकर्ताओं को रिकवर करने दें:

• केवल सबसे कम रिस्की रूट्स के लिये अस्थायी कैप बढ़ाएँ (अक्सर रीड्स) और एरर दर देखें।
• जांच के दौरान ज्ञात अच्छे ग्राहकों के लिये एक छोटा allowlist जोड़ें।
• ग्लोबल लिमिट घटाने की बजाय ख़ास रिस्की रूट्स को कड़ा करें।
• साझा नेटवर्क को ब्लॉक करने से बचने के लिये मजबूत पहचान चालू करें (API की अनिवार्य करें, IP पर निर्भरता घटाएँ)।
• सैंपल्स कैप्चर करें: टॉप कीज़, टॉप IPs, यूज़र‑एजेंट्स, और सटीक पेलोड पैटर्न्स।

किसी ग्राहक के लिये लिमिट बढ़ाने से पहले उनका सामान्य रिक्वेस्ट पैटर्न, एंडपॉइंट मिक्स, और क्या वे बैच या बैकऑफ जोड़ सकते हैं ये चेक करें। साथ ही पुष्टि करें कि वे कई एप्स में एक ही की शेयर नहीं कर रहे।

महीनेवार समीक्षा करें: टॉप लिमिटेड एंडपॉइंट्स, सीमा हिट करने वाला ट्रैफ़िक का प्रतिशत, नए हाई‑कॉस्ट रूट्स, और क्या आपके कोटे अभी भी वास्तविक उपयोग से मेल खाते हैं।

उदाहरण परिदृश्य: असली सार्वजनिक API की रक्षा करते हुए यूज़र्स को न तोड़ना

मान लीजिए आप एक सार्वजनिक API चलाते हैं जिसे दो ऐप्स प्रयोग करते हैं: एक ग्राहक पोर्टल (उच्च वॉल्यूम, स्थिर ट्रैफ़िक) और एक इंटरनल एडमिन टूल (कम वॉल्यूम, पर शक्तिशाली क्रियाएँ)। दोनों API कीज़ का उपयोग करते हैं, और पोर्टल के पास यूज़र्स के लिये एक लॉगिन एंडपॉइंट भी है।

एक दोपहर, एक पार्टनर ने एक बग्गी इंटीग्रेशन शिप कर दिया। वह असफल रिक्वेस्ट्स को कड़ी लूप में रीट्राइ कर रहा है और एक ही API की से 200 रिक्वेस्ट्स प्रति सेकंड भेज रहा है। बिना गार्डरेल्स के, वह एक की बाकी सबको दबाकर रख सकती है।

प्रति‑कुंजी सीमाएँ ब्लास्ट‑रेडियस को सीमित कर देती हैं। बग्गी की अपनी प्रति‑मिनट कैप तक पहुँचती है, 429 रिस्पॉन्स मिलती है, और बाकी ग्राहक काम करते रहते हैं। आप महँगे एंडपॉइंट्स (जैसे एक्सपोर्ट्स) के लिए अलग, निचली लिमिट भी रख सकते हैं ताकि "अनुमत" ट्रैफ़िक भी डेटाबेस को ओवरलोड न कर पाए।

इसी समय, एक ब्रूट‑फोर्स लॉगिन प्रयास ऑथ एंडपॉइंट को हिट कर रहा है। पूरा IP रेंज ब्लॉक करने के बजाय (जो NAT के पीछे असली उपयोगकर्ताओं को प्रभावित कर सकता है), आप इसे धीमा करते हैं और फिर व्यवहार के आधार पर लॉकआउट करते हैं: एक अकाउंट के प्रति बहुत सारी फेल्ड कोशिशें प्लस एक छोटे विंडो में प्रति‑IP संकेत। अटैकर को धीरे‑धीरे लंबी वेट मिलती है, फिर अस्थायी लॉक।

एक असली ग्राहक जिसने कुछ गलत पासवर्ड टाइप किए हों, वह रिकवर कर सकता है क्योंकि आपकी प्रतिक्रियाएँ स्पष्ट और सुसंगत हैं:

• 429 के साथ Retry-After ताकि क्लाइंट जान सके कब पुन: प्रयास करना है
• एक छोटा लॉकआउट विंडो (उदा., 10–15 मिनट), स्थायी बैन नहीं
• स्थिर एरर संदेश जो यह उजागर न करें कि अकाउंट मौजूद है या नहीं

फिक्स की पुष्टि के लिए आप कुछ मेट्रिक्स देखें:

• API की और एंडपॉइंट के अनुसार 429 दर
• ऑथ फेल्योर दर और लॉकआउट काउंट्स
• घटना के दौरान P95 लेटेंसी और डेटाबेस CPU
• प्रभावित यूनिक कीज़ की संख्या (छोटी होनी चाहिए)

यह वही सुरक्षात्मक रेट‑लिमिटिंग है जो बैकएंड को ढाल देती है बिना सामान्य उपयोगकर्ताओं को दंडित किए।

अगले कदम: एक छोटा पॉलिसी लागू करें और सुधारते जाएँ

पहले दिन पर परफेक्ट मॉडल की ज़रूरत नहीं है। एक छोटा, स्पष्ट पॉलिसी रखें और वास्तविक उपयोग के आधार पर उसे सुधारें।

एक ठोस पहला वर्शन आमतौर पर तीन भागों पर आधारित होता है:

• एक प्रति‑की बेसलाइन (रिपोर्ट्स प्रति मिनट) जो अधिकांश एंडपॉइंट्स को कवर करे
• महँगे एंडपॉइंट्स (सर्च, एक्सपोर्ट, फ़ाइल अपलोड, जटिल रिपोर्ट्स) पर कड़े कैप
• क्लाइंट को क्या करना है यह बताने वाला एक छोटा 429 संदेश

लॉकआउट केवल उन्हीं जगहों पर जोड़ें जहाँ दुरुपयोग का जोखिम अधिक हो और इरादा आसानी से समझा जा सके। साइनअप, लॉगिन, पासवर्ड‑रीसेट और टोकन निर्माण सामान्य उम्मीदवार हैं। लॉकआउट्स को पहले छोटा रखें (मिनट्स, दिनों नहीं), और प्रोग्रेसिव फ्रिक्शन पसंद करें: पहले धीमा करें, फिर अस्थायी ब्लॉक, फिर मजबूत जाँच आवश्यक करें।

पॉलिसी को सरल भाषा में लिखें ताकि सपोर्ट बिना इंजीनियरिंग मदद के इसे समझा सके। इसमें बताएं कि क्या सीमित है (प्रति API की, प्रति IP, प्रति अकाउंट), रिसेट विंडो, और ग्राहक कैसे रिकवर कर सकते हैं।

यदि आप यह नई बैकएंड बनाते समय लागू कर रहे हैं, तो AppMaster व्यवहारिक रूप से उपयुक्त हो सकता है: आप APIs बना सकते हैं, बिजनेस वर्कफ़्लोज़ (काउंटर्स और लॉकआउट फैसले सहित) विनिर्दिष्ट कर सकते हैं विजुअली, और फिर AppMaster Cloud पर डिप्लॉय कर सकते हैं या ज़रूरत पड़ने पर जनरेटेड सोर्स कोड एक्सपोर्ट कर सकते हैं।