HTTP 429 और Retry-After: दोबारा अनुरोध भेजने की सुरक्षित योजना

पहले पहचानें कि 429 किस परत ने भेजा

अनुरोध का समय, endpoint, method, status, request ID और retry संबंधी response headers दर्ज करें। Authorization और निजी डेटा लॉग में न रखें। जांचें कि जवाब अपेक्षित API, reverse proxy या CDN के नियम से आया है। केवल ब्रांड वाला error page सीमा की नीति नहीं बताता।

सीमा IP, प्रमाणित उपयोगकर्ता, एप्लिकेशन या किसी संसाधन पर लागू हो सकती है। response body और प्रदाता dashboard में quota का प्रकार देखें। प्रति मिनट दर, साथ चल रहे अनुरोध और दैनिक allowance अलग समस्याएं हैं; धीमी कतार खत्म दैनिक quota वापस नहीं लाती।

• क्या अधिक वास्तविक jobs चले या एक job बार-बार retry करने लगा?
• क्या कई सेवाएं, tabs या API keys एक खाते का allowance साझा करते हैं?
• सीमा अनुरोध, सक्रिय अनुरोध, tokens या किस संसाधन पर है?
• क्या बताया गया recovery समय उपयोगकर्ता के इस काम की समयसीमा में आता है?

Retry-After की इकाई सही समझें

Retry-After गैरऋणात्मक पूर्णांक सेकंड या HTTP date हो सकता है। 12 का अर्थ जवाब मिलने के बाद बारह सेकंड है, मिलीसेकंड नहीं। तारीख हो तो भरोसेमंद घड़ी से बचा अंतर निकालें। बीती तारीख बिना रुके retry करने का कारण नहीं बनती।

यदि कतार प्रतीक्षा कर सकती है तो सही server delay को न्यूनतम मानें और workers के फिर शुरू होने में थोड़ा यादृच्छिक अंतर रखें। delay बची deadline से अधिक हो तो काम रोकें या पुनर्निर्धारित करें। अपनी मनमानी सीमा लगाकर server की प्रतीक्षा चुपचाप छोटी न करें।

पूरी साझा कतार का बजट बनाएं

मान लें पूरे खाते को 120 अनुरोध प्रति मिनट मिलते हैं और job में 600 अनुरोध हैं। दूसरे काम न हों तब भी संख्या के हिसाब से कम से कम पांच मिनट चाहिए। सभी 600 दस सेकंड में भेजकर बाकी समय सोना burst ही है; मिनट का औसत ठीक दिखने पर भी सेवा मना कर सकती है।

दूसरे कामों के लिए जगह छोड़कर 90 प्रति मिनट का लक्ष्य लें। यह 1.5 प्रति सेकंड और लगभग 667 मिलीसेकंड का अंतर है। 600 अनुरोधों को लगभग 400 सेकंड चाहिए, response time और retries अलग हैं। यह योजना है, हर प्रदाता की rolling window से मेल खाने का वादा नहीं।

औसत response दो सेकंड हो तो स्थिर workload में Little’s Law से औसत concurrency 1.5 × 2 = 3 निकलती है। semaphore सक्रिय अनुरोध सीमित करे और साझा rate limiter उनके शुरू होने की दर। एक नियंत्रण दूसरे की जगह नहीं लेता; retries भी इसी बजट में गिनें।

Example workload assumptions:
Account allowance: 120 requests/minute
Operating target: 90 requests/minute = 1.5 requests/second
600 requests / 1.5 requests/second = 400 seconds
Average concurrency at 2 seconds/response: 1.5 × 2 = 3

delay न मिले तो सीमित backoff और jitter रखें

बार-बार विफलता पर प्रतीक्षा की खिड़की बढ़ाएं और वास्तविक प्रतीक्षा उसमें यादृच्छिक चुनें। एक, दो, चार और आठ सेकंड की windows तथा अलग कुल deadline एक उदाहरण हैं। jitter सभी workers को ठीक एक समय लौटने से रोकता है।

नीचे की function केवल delay निकालती है; पूरा retry client नहीं चलाती। caller को deadline, attempt cap, cancellation और operation की सुरक्षा लागू करनी होगी। browser में JavaScript को Retry-After पढ़ने के लिए सर्वर से CORS द्वारा header expose करना भी जरूरी हो सकता है।

function retryDelayMs(retryAfter, attempt, nowMs = Date.now()) {
  const text = String(retryAfter ?? "").trim();
  if (/^\d+$/.test(text)) {
    const milliseconds = Number(text) * 1000;
    return Number.isSafeInteger(milliseconds) ? milliseconds : Infinity;
  }
  if (/^(Mon|Tue|Wed|Thu|Fri|Sat|Sun), \d{2} (Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d{4} \d{2}:\d{2}:\d{2} GMT$/.test(text)) {
    const dateMs = Date.parse(text);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - nowMs);
  }
  const windowMs = Math.min(8000, 1000 * 2 ** attempt);
  return Math.floor(Math.random() * windowMs);
}
// Example policy: at most 4 retries and a 30-second total deadline.
// If the required wait exceeds the remaining deadline, stop.

सिर्फ सुरक्षित रूप से दोहराए जाने वाले काम दोहराएं

resource पढ़ना और भुगतान बनाना अलग काम हैं। write दोहराने से पहले idempotency अनुबंध और पहले प्रयास के लागू हो चुकने की संभावना जांचें। supported हो तो उसी logical operation की वही idempotency key रखें; हर बार नई key अलग operations बना सकती है।

SDK पहले से अंदर retry कर सकता है। उसके ऊपर दूसरी retry loop लगाने से अनुरोध कई गुना हो सकते हैं। सभी परतों का कुल network attempt cap लिखें। उपयोगकर्ता को साफ retry-later स्थिति दिखाएं; लंबे छिपे queue के लिए हमेशा घूमता बटन न रखें।

• एक कुल deadline रखें और queue तक cancellation पहुंचाएं।
• साझा allowance पर concurrency और start rate दोनों सीमित करें।
• रुकने या retry से पहले response के संसाधन छोड़ें।
• quota खत्म हो या provider स्थायी error बताए तो बंद करें।
• attempts और final outcomes लॉग करें ताकि monitoring में retry दिखे।

छोटी नियंत्रित batch से सुधार की पुष्टि करें

बीस reads जैसे गिने जा सकने वाले काम से शुरू करें। शुरुआती attempts, retries, सफल responses और अंतिम failures अलग दर्ज करें। देखें कि वास्तविक spacing और active count योजना से मेल खाते हैं। ज्ञात Retry-After वाला 429 simulate करें; live सेवा को बार-बार दबाव देकर जांचना जरूरी नहीं।

request-rate calculator से सेकंड औरमिनट की दर बदलें और concurrency calculator से latency की धारणा जांचें। फिर इसे वास्तविक provider limits से मिलाएं। 429 बने रहें तो केवल delay बढ़ाने से पहले साझा callers और quota का प्रकार देखें।