API में अनुरोध दर सीमित करना क्या है, और मैं 429 को कैसे संभालूँ?

ज़्यादा ट्रैफ़िक वाला भेजने वाला अपने सभी संदेश कतार में डालने से पहले ही अपना अनुरोध बजट खत्म कर सकता है। बचा हुआ कोटा पढ़कर वह और कॉल अस्वीकार होने से पहले अपनी गति धीमी कर सकता है।

Bird मेरी सीमा कैसे तय करता है?

Bird संबंधित समूह के लिए पहले एक आधार दर लागू करता है, फिर प्लान से मिली कोई भी बढ़ोतरी और उसके बाद कोई भी ओवरराइड। ओवरराइड बाकी मानों की जगह ले लेता है।

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

हर बजट का दायरा ऑपरेशन पर निर्भर करता है:

बिना प्रमाणीकरण वाली सीमाएँ तय थ्रेशोल्ड का उपयोग करती हैं। अलग-अलग एंडपॉइंट को सौंपे गए समूहों के लिए दर सीमा गाइड देखें।

भेजने की सीमाएँ प्राप्तकर्ताओं को नहीं, अनुरोधों को गिनती हैं। एक बैच अनुरोध कई संदेशों को कतार में डाल सकता है। उसके समूह का कोटा अलग हो सकता है।

एंडपॉइंट बदलने से पहले लाइव कोटा और एक बैच में रखे जा सकने वाले प्राप्तकर्ताओं की संख्या की तुलना करें। केवल एक प्राप्तकर्ता वाले बैच से थ्रूपुट में शायद कोई बढ़त न मिले।

मैं प्रतिक्रिया हेडर कैसे पढ़ूँ?

कोटा और विंडो के लिए RateLimit-Policy पढ़ें, फिर बचे हुए अनुरोधों और रीसेट तक के समय के लिए RateLimit पढ़ें।

उदाहरण के लिए:

RateLimit-Policy: "email_send";q=1000;w=60
RateLimit: "email_send";r=842;t=35

यह उदाहरण हर 60 सेकंड की विंडो में 1,000 अनुरोधों की अनुमति देता है। इसमें 842 अनुरोध बचे हैं, और रीसेट में 35 सेकंड बाकी हैं।

ये संख्याएँ केवल हेडर को समझाने के लिए हैं। ये किसी कोटे का वादा नहीं हैं। अपने क्लाइंट को लौटाए गए मान पढ़ें।

एक प्रतिक्रिया में एक से अधिक नीतियाँ हो सकती हैं। अगला अनुरोध निर्धारित करते समय हर लागू नीति का ध्यान रखें।

दर-सीमा विफल होने पर क्या लौटाया जाता है?

API की सीमा समाप्त होने पर सेकंड में Retry-After के साथ 429 Too Many Requests लौटाया जाता है। दर-सीमा हेडर समाप्त हो चुके समूह की पहचान करते हैं। उस समूह का शेष कोटा r=0 होता है।

त्रुटि प्रतिक्रिया में ये फ़ील्ड शामिल होते हैं:

{
  "error": {
    "type": "rate_limit_error",
    "code": "E01003",
    "name": "RateLimited"
  }
}

अपने हैंडलर में type या code का मिलान करें। पढ़ने योग्य संदेश बदल सकता है, जबकि समस्या से उबरने का तरीका वही रहता है।

मेरे क्लाइंट को 429 कैसे संभालना चाहिए?

Retry-After तक प्रतीक्षा करें, फिर सीमित बैकऑफ़ नीति के साथ फिर से प्रयास करें। उसी write को दोहराते समय वही idempotency कुंजी रखें।

एक ही समूह बजट का उपयोग करने वाले वर्करों के बीच तालमेल रखें। किसी वर्कर की पिछली प्रतिक्रिया उन अनुरोधों का हिसाब नहीं रख सकती जो उसके बाद दूसरे वर्करों ने भेजे हैं।

जैसे-जैसे बचा हुआ कोटा घटे, अनुरोधों की गति धीमी करें। एक साथ चल रहे ट्रैफ़िक के लिए फिर से प्रयास का रास्ता बनाए रखें। गति नियंत्रित करने से विफलताएँ कम होती हैं, लेकिन इससे यह गारंटी नहीं मिलती कि किसी भी कॉल को 429 नहीं मिलेगा।

Bird SDK 429 पर फिर से प्रयास करना और Retry-After संभालते हैं। वे आपकी सभी प्रक्रियाओं के बीच साझा कतार का तालमेल नहीं करते।

अगर कोटा आपके वर्कलोड के लिए कम ही रहता है, तो override के लिए Bird से संपर्क करें। ज़्यादा कुंजियाँ बनाने से पूरे संगठन पर लागू भेजने की सीमा नहीं बढ़ती।

क्या दर-सीमित अनुरोध ने कोई काम किया है?

Bird दर-सीमित अनुरोध को माँगा गया काम करने से पहले ही अस्वीकार कर देता है। इस अस्वीकृति से उसकी idempotency कुंजी खर्च नहीं होती। प्रतीक्षा के बाद उसी कुंजी के साथ फिर से प्रयास करें।

अगर limiter सीमा का मूल्यांकन नहीं कर पाता, तो वह अनुरोधों को आगे जाने देता है। इसलिए कोटा के मूल्यांकन में आई समस्या अपने आप 429 नहीं देती।

दूसरी विफलताओं के लिए भी idempotency प्रबंधन बनाए रखें। write शुरू होने के बाद सर्वर त्रुटि हो सकती है या प्रतिक्रिया खो सकती है।