HTTP 429 ও Retry-After: নিরাপদে আবার অনুরোধ পাঠানোর পরিকল্পনা

কোন স্তর 429 পাঠিয়েছে আগে দেখুন

অনুরোধের সময়, endpoint, method, status, request ID ও retry-সংক্রান্ত response headers লিখে রাখুন। Authorization ও ব্যক্তিগত তথ্য লগে রাখবেন না। উত্তর মূল API, reverse proxy নাকি CDN-এর নিয়ম থেকে এসেছে দেখুন। পরিচিত লোগোসহ ত্রুটি পাতা একাই সীমার নীতি প্রমাণ করে না।

সীমা IP, যাচাইকৃত ব্যবহারকারী, অ্যাপ্লিকেশন বা নির্দিষ্ট সম্পদের ওপর হতে পারে। response body ও প্রদাতার dashboard থেকে কোন quota ফুরিয়েছে দেখুন। মিনিটের হার, একসঙ্গে সক্রিয় অনুরোধ ও দৈনিক allowance আলাদা সমস্যা; ধীর সারি শেষ হওয়া দৈনিক quota ফিরিয়ে আনে না।

• আসল কাজ বেড়েছে, নাকি একই কাজ বারবার retry করছে?
• একাধিক সেবা, tab বা API key কি একই অ্যাকাউন্টের allowance ভাগ করে?
• সীমাটি অনুরোধ, সক্রিয় অনুরোধ, token নাকি অন্য সম্পদের?
• নথির recovery সময় কি ব্যবহারকারীর কাজের বাকি সময়ে সম্ভব?

Retry-After-এর একক ঠিকভাবে পড়ুন

Retry-After অঋণাত্মক পূর্ণসংখ্যায় সেকেন্ড অথবা HTTP date হতে পারে। 12 মানে উত্তর পাওয়ার পরে বারো সেকেন্ড, মিলিসেকেন্ড নয়। তারিখ থাকলে নির্ভরযোগ্য ঘড়ি দিয়ে বাকি সময় বের করুন। ইতিমধ্যে পেরোনো তারিখ বিরতিহীন retry loop-এর কারণ নয়।

কাজ অপেক্ষা করতে পারলে সঠিক server delay-কে ন্যূনতম ধরুন এবং বহু worker একসঙ্গে ফেরার বদলে সামান্য এলোমেলো ব্যবধান রাখুন। delay বাকি deadline ছাড়ালে কাজ বন্ধ বা পুনর্নির্ধারণ করুন। নিজের ছোট সীমা বসিয়ে সার্ভারের বলা সময় কমিয়ে দেবেন না।

প্রতিটি worker নয়, পুরো সারির বাজেট করুন

ধরা যাক পুরো অ্যাকাউন্টে মিনিটে 120 অনুরোধ চলে, কাজটিতে 600 অনুরোধ আছে। অন্য কাজ না থাকলেও সংখ্যার হিসেবে অন্তত পাঁচ মিনিটের allowance লাগে। 600 অনুরোধ দশ সেকেন্ডে পাঠিয়ে পরে ঘুমানোও burst; মিনিটের গড় ঠিক হলেও সেবা তা প্রত্যাখ্যান করতে পারে।

অন্য কাজের জায়গা রেখে লক্ষ্য 90 অনুরোধ প্রতি মিনিট ধরা হলো। এটি সেকেন্ডে 1.5, অর্থাৎ প্রায় 667 মিলিসেকেন্ড ব্যবধান। 600 অনুরোধে প্রায় 400 সেকেন্ড লাগবে, উত্তরের সময় ও retry বাদে। এটি পরিকল্পনার হিসাব, প্রতিটি প্রদাতার window-এর নিশ্চয়তা নয়।

গড় response দুই সেকেন্ড হলে স্থিতিশীল কাজের জন্য Little’s Law-এ গড় concurrency 1.5 × 2 = 3 হয়। semaphore সক্রিয় অনুরোধের সংখ্যা বেঁধে দেবে, যৌথ rate limiter শুরু করার হার নিয়ন্ত্রণ করবে। একটি অন্যটির বিকল্প নয়; retry-ও একই বাজেটে গুনুন।

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

সময় না জানালে সীমিত backoff ও jitter দিন

পুনঃপুন ব্যর্থতায় অপেক্ষার window বাড়িয়ে তার মধ্যে আসল সময় এলোমেলোভাবে বাছা যায়। এক, দুই, চার ও আট সেকেন্ডের window এবং আলাদা মোট deadline একটি উদাহরণ। jitter থাকলে সব worker ঠিক একই মুহূর্তে আবার চাপ দেয় না।

নিচের function শুধু delay গণনা করে; অনুরোধ পাঠায় না বা সম্পূর্ণ retry client বানায় না। caller-কে deadline, attempt cap, cancellation ও কাজ পুনরাবৃত্তির নিরাপত্তা নিশ্চিত করতে হবে। browser-এ JavaScript দিয়ে Retry-After পড়তে সার্ভারের CORS exposure-ও লাগতে পারে।

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 পড়া আর payment তৈরি এক কাজ নয়। write আবার পাঠানোর আগে idempotency-এর চুক্তি ও আগের চেষ্টা ইতিমধ্যে কার্যকর হওয়ার সম্ভাবনা দেখুন। সমর্থিত হলে একই logical operation-এর একই key রাখুন; নতুন key প্রতিবার আলাদা operation করতে পারে।

SDK নিজেই retry করতে পারে। তার ওপর আরেক loop দিলে traffic বহুগুণ হতে পারে। সব স্তরের সর্বোচ্চ network attempts লিখুন। ব্যবহারকারীকে পরিষ্কার retry-later অবস্থা দেখান; দীর্ঘ গোপন সারির আড়ালে বাটন অনির্দিষ্টকাল ঘুরতে রাখবেন না।

• একটি মোট deadline দিন, cancellation অপেক্ষমাণ কাজেও পৌঁছাক।
• যৌথ allowance-এ concurrency এবং start rate দুটোই বাঁধুন।
• অপেক্ষা বা retry-এর আগে response-এর সম্পদ ছেড়ে দিন।
• quota শেষ বা provider স্থায়ী ব্যর্থতা বললে থামুন।
• attempts ও final outcomes লগে রাখুন যেন retry দৃশ্যমান হয়।

ছোট নিয়ন্ত্রিত ব্যাচে সমাধান যাচাই করুন

বিশটি read-এর মতো গোনা যায় এমন ব্যাচ নিন। প্রাথমিক attempt, retry, সফল উত্তর ও চূড়ান্ত ব্যর্থতা আলাদা লিখুন। দেখা spacing ও সক্রিয় সংখ্যা পরিকল্পনার সঙ্গে মেলে কি না দেখুন। জানা Retry-After-সহ 429 simulate করুন; live সেবাকে বারবার চাপে ফেলতে হবে না।

request-rate calculator-এ সেকেন্ড ও মিনিটের হার বদলান, concurrency calculator-এ latency-এর অনুমান মিলিয়ে দেখুন। তারপর সেবার আসল সীমার সঙ্গে পরিকল্পনা তুলনা করুন। 429 থাকলে অন্ধভাবে delay না বাড়িয়ে যৌথ callers ও quota-এর ধরন খুঁজুন।