पाठ 17 / 25

Retries और Exponential Backoff

अस्थायी errors को बढ़ती देरी से retry करें और स्थायी errors पर हार मान लें।

सही errors को retry करें

Network की रुकावटें, rate limits (HTTP 429) और server errors (5xx) अक्सर अस्थायी होते हैं, इसलिए प्रतीक्षा के बाद retry सफल हो सकता है। ग़लत अनुरोध (400) या अनुमति errors (403) स्थायी हैं: retry सिर्फ़ पैसा बर्बाद करता है। सीमा के साथ exponential backoff (1s, 2s, 4s, 8s…) उपयोग करें, थोड़ा random jitter जोड़ें ताकि कई clients एक साथ retry न करें, और कोशिशें सीमित रखें।

देरी की अनुसूची

यह जैसा दिखाया गया वैसा ही चला: देरी दोगुनी होती है जब तक 8 सेकंड की सीमा न आ जाए। असली कोड में हर एक में random.uniform(0, 0.5) जोड़ें।

def delays(base=1.0, cap=8.0, tries=5):
    return [min(cap, base * 2 ** i) for i in range(tries)]

print(delays())

Output:

[1.0, 2.0, 4.0, 8.0, 8.0]

Retry-After का सम्मान करें

Response में Retry-After header हो तो अपनी अनुसूची की जगह कम से कम उतनी देर रुकें। कई SDKs पहले से अस्थायी errors को retry करते हैं; अपनी परत जोड़ने से पहले जाँचें।

त्वरित जाँच: प्रतीक्षा के बाद किस error को retry करना आम तौर पर सार्थक है?

  • 400 Bad Request
  • 403 Forbidden
  • 429 Too Many Requests
  • ग़लत ID के लिए 404 Not Found
Answer

429 Too Many Requests — Rate limits अस्थायी हैं; बाक़ी तब तक उसी तरह विफल होंगे जब तक अनुरोध न बदले।