Rate Limit Headers နှင့် Handling Strategy

နားလည်ထားရမယ့် အချက်

Rate limit ကို ထိလိုက်ရင် 429 response ရမယ်ဆိုတာ သင်သိပြီးသားပါ။ API အများစုက request တိုင်းမှာ response headers ထဲမှာ သင့်လက်ရှိ standing ကို ဖော်ပြပေးပြီး ဒီရလဒ်ကို ရှောင်ဖို့ တက်ကြွစွာ ကူညီပေးတယ်ဆိုတာကတော့ prerequisite course မှာ မပါခဲ့ပါဘူး။

• Limit — လက်ရှိ window အတွင်း ခွင့်ပြုထားတဲ့ request အများဆုံးအရေအတွက်။
• Remaining count — အခုချိန်မှာ ကျန်နေသေးတဲ့ request အရေအတွက်။
• Reset time — window ပြန်စတင်ပြီး remaining ပြန်တက်လာမယ့် အချိန်။

Strategic ပြောင်းလဲမှုကတော့ ဒီ header အချက်အလက်ကို retry နဲ့ backoff အသိပညာနဲ့ ပေါင်းစပ်တာပါ။ Request တစ်ခုစီမပို့ခင် remaining count ကို ဖတ်ပြီး သုညရောက်ခင် တက်ကြွစွာ လျှော့ချပါ — ဒါက rate limiting ကို budget တစ်ခု ဖြစ်စေပါတယ်။

429 ရောက်လာရင် Retry-After header ကို ပါလေ့ရှိပါတယ် — တိုက်ရိုက်လေးစားပါ။ မပါခဲ့ရင် jitter ပါတဲ့ exponential backoff ဆီ ပြန်ကြည့်ပါ — retry တစ်ခုချင်း fail ရင် စောင့်ချိန်ကို နှစ်ဆတိုးပါ။

RATE LIMIT CHECK AND BACKOFF FLOW
---------------------------------
-----
Before each request: check remaining count
        |
   +----+----+
   |         |
remaining>0   remaining=0
   |         |
   v         v
Send request   Wait (exponential backoff + jitter)
   |         |
   v         v
Update remaining   Retry request
from response       |
                     v
                Update remaining, continue

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

အောက်က code က remaining request နှစ်ခုပဲ ကျန်တော့တဲ့ rate limiter တစ်ခုအပေါ် pending API call လေးခုပါတဲ့ queue ကို model လုပ်ထားပါတယ်။ processQueue က request တစ်ခုစီမပို့ခင် remaining count ကို အရင်စစ်ပါတယ်။

ပထမ call နှစ်ခုက ပုံမှန် အောင်မြင်သွားပြီး remaining ကို လျှော့ပါတယ်။ တတိယ call ရောက်တော့ remaining သုညထိ ကျသွားလို့ RATE_LIMITED report လုပ်ပြီး backoff wait ကို simulate လုပ်ပါတယ်။

Run ကြည့်ပြီး action field ကို ကြည့်ပါ — SENT နှစ်ခု၊ back off လုပ်ခဲ့ရတဲ့ တစ်ခု၊ refresh ဖြစ်ထားတဲ့ count ကို သုံးပြီး နောက် SENT တစ်ခု ထပ်ပါတယ်။

• API အများစုက response headers ထဲမှာ ကျန်ရှိနေသေးတဲ့ rate-limit capacity ကို ဖော်ပြပေမယ့် header name အတိအကျက provider အလိုက် ကွာနိုင်ပါတယ်။
• 429 နဲ့ ငြင်းပယ်ခံရအောင် မစောင့်ဘဲ request burst မပို့ခင် ကျန်ရှိသေးတဲ့ capacity ကို အရင်စစ်ပါ။
• Retry-After hint ပါလာရင် လေးစားပါ၊ မပါရင်တော့ jitter ပါတဲ့ exponential backoff ဆီ fallback လုပ်ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

function processQueue(queue, remainingStart, limit) {
  let remaining = remainingStart;
  const log = [];

  queue.forEach((call) => {
    if (remaining > 0) {
      remaining--;
      log.push({ call, action: "SENT", remainingAfter: remaining });
    } else {
      const backoffMs = 2000;
      remaining = limit - 1;
      log.push({ call, action: `RATE_LIMITED -> waited ${backoffMs}ms -> retried, SENT`, remainingAfter: remaining });
    }
  });

  return log;
}

const queue = ["GET /users", "GET /orders", "GET /invoices", "GET /reports"];
console.log(processQueue(queue, 2, 5));

[
  { call: 'GET /users', action: 'SENT', remainingAfter: 1 },
  { call: 'GET /orders', action: 'SENT', remainingAfter: 0 },
  {
    call: 'GET /invoices',
    action: 'RATE_LIMITED -> waited 2000ms -> retried, SENT',
    remainingAfter: 4
  },
  { call: 'GET /reports', action: 'SENT', remainingAfter: 3 }
]

MDN — 429 Too Many Requests — API Integration & Webhooks