मुख्य सामग्री पर जाएं

Rate limits

Rate limit एक निर्दिष्ट समय अवधि में किसी application द्वारा API को किए जा सकने वाले अनुरोधों की अधिकतम संख्या को परिभाषित करता है। यह mechanism services के समग्र स्वास्थ्य और विश्वसनीयता बनाए रखने के लिए महत्वपूर्ण है।

हम rate limiting का उपयोग क्यों करते हैं​

API stability and performance
  • एक client को अत्यधिक अनुरोधों के साथ servers को overwhelm करने से रोकता है।
  • सभी clients के लिए consistent और predictable response times सुनिश्चित करता है।
  • Backend services को अप्रत्याशित traffic spikes से बचाता है।
  • Infrastructure पर stable और controlled load pattern बनाए रखता है।
Security
  • Brute force जैसे हमले के प्रयासों के खिलाफ रक्षा को मजबूत करता है।
  • Distributed denial-of-service (DDoS) के जोखिम को कम करता है।
  • खराब ढंग से implemented integrations के कारण होने वाले प्रभाव को कम करता है।
  • Compromised API credentials के परिणामस्वरूप होने वाले संभावित नुकसान को सीमित करता है।
Resource allocation
  • सभी clients के लिए API resources तक संतुलित पहुँच सुनिश्चित करता है।
  • कुछ द्वारा दुरुपयोग को अन्य उपयोगकर्ताओं के अनुभव को ख़राब करने से रोकता है।
  • व्यावसायिक मानदंडों और ज़रूरतों के अनुसार traffic को प्राथमिकता देने की अनुमति देता है।
  • अधिक कुशल और sustainable API उपभोग प्रथाओं को प्रोत्साहित करता है।

Rate limiting कैसे काम करता है​

प्रत्येक API call अनुमत requests-per-second limit की ओर count होती है। डिफ़ॉल्ट मान 10 RPS प्रति tenant है। Limit से अधिक होने पर, API HTTP 429 Too Many Requests लौटाती है।

अपनी Onboarding team से पुष्टि करें

Exact limits tenant के अनुसार configure की जाती हैं। High-throughput integrations के लिए sizing करने से पहले अपनी Onboarding team से संपर्क करके अपने account पर लागू limits की पुष्टि करें।

429 त्रुटियाँ संभालना​

Rate limit increase का अनुरोध करें

यदि आपके operation में request volume में वृद्धि होगी (अस्थायी या स्थायी), तो Unico team को अपने वातावरण के लिए rate limit बढ़ाने के लिए सूचित करें। यह अनुरोध volume वास्तव में बढ़ने से पहले किया जाना चाहिए ताकि आपकी application को निष्क्रिय होने से बचाया जा सके।

Application व्यवहार की समीक्षा करें
  • अकुशल API उपयोग patterns की पहचान के लिए अपने code का ऑडिट करें।
  • अनजाने loops या अनावश्यक API calls जांचें।
  • बड़े bursts भेजने के बजाय अनुरोधों को समय के साथ अधिक समान रूप से वितरित करें।
Caching implement करें
  • बार-बार access किए गए डेटा को cache करें जो शायद ही बदलता है।
  • OAuth2 access token का उपयोग उसके पूर्ण 1-घंटे TTL के लिए करें — प्रति अनुरोध POST /oauth2/token call न करें।
  • उचित cache invalidation strategies implement करें।
Polling के बजाय webhooks का उपयोग करें

GET /client/v1/process/\{id\} poll करने के बजाय PROCESS_STATE_FINISHED के लिए Webhooks and Events subscribe करें। एक polling loop भारी traffic पर GET-process budget को आसानी से समाप्त कर सकता है।

Limit से टकराने पर क्या होता है​

प्लेटफ़ॉर्म लौटाता है:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Headerअर्थ
Retry-Afterपुनः प्रयास करने से पहले प्रतीक्षा करने के सेकंड। इसका सम्मान करें।

यदि Retry-After अनुपस्थित है, तो exponential backoff (1s, 2s, 4s, 8s, …) 60s पर capped पर वापस जाएं।

Concurrency considerations​

Rate limits प्रति मिनट अनुरोधों को cap करती हैं, लेकिन प्लेटफ़ॉर्म पर infrastructure स्तर पर concurrency caps भी हैं। भले ही आपके पास 100 requests/minute का budget हो, सभी 100 को एक ही सेकंड में fire करना उन्हें मिनट भर फैलाने से ज़्यादा reject होने की संभावना है।

High-throughput integrations के लिए, bursts के बजाय steady RPS target करें।

Trully के Webhook V2 के लिए अपने स्वयं के delivery quotas हैं। Webhook server से 1 मिनट के भीतर प्रतिक्रिया की अपेक्षा है; धीमी प्रतिक्रियाएँ drop की जाती हैं (उपयोगकर्ता की process प्रभावित नहीं होती)। Consistent processing के लिए, webhook को तेज़ी से स्वीकार करें और इसे asynchronously process करें।

आगे क्या​

अंतिम अपडेट को