လွယ်လွယ်ပြောရရင် rate limiting ဆိုတာ တစ်ယောက် (သို့) program တစ်ခုက server ကို တစ်မိနစ်/တစ်နာရီအတွင်း ဘယ်နှစ်ခါ တောင်းဆိုလို့ရလဲ ကန့်သတ်ထားတဲ့ စည်းမျဉ်း။ အကန့်အသတ် ကျော်သွားရင် server က “ခဏရပ်၊ နားဦး” လို့ ပြန်ပြောတယ်။

ဥပမာ ပြောရအောင် — ATM စက်ကို စဉ်းစားကြည့်ပါ။ ဘဏ်က တစ်နေ့ကို ငွေထုတ်လို့ရတဲ့ အများဆုံး ပမာဏ ကန့်သတ်ထားတယ် — သိန်း ၃၀ ဆိုပါစို့။ ဒါက မင်းကို ညှဉ်းပန်းနေတာ မဟုတ်ဘူး။ ငွေအလုံအလောက် ရှိအောင်၊ လိမ်လည်မှုကနေ ကာကွယ်ဖို့၊ လူတိုင်း မျှမျှတတ သုံးနိုင်အောင် လုပ်ထားတာ။ API rate limiting ကလည်း အတိအကျ ဒီစိတ်ကူးပဲ — server ရဲ့ အရင်းအမြစ်ကို လူတိုင်း မျှဝေသုံးနိုင်အောင်၊ တစ်ယောက်တည်း အကုန်ယူမသွားအောင် ကန့်သတ်ထားတာ။

ဘာလို့ ကန့်သတ်ရတာလဲ။ အကြောင်းရင်း ၄ ခု ရှိတယ်။

Server မကျအောင် — လူ တစ်သောင်းက တစ်ပြိုင်နက် တစ်စက္ကန့်ကို အကြိမ် တစ်ထောင်စီ တောင်းနေရင် ဘယ် server မဆို ကျသွားမယ်။ Rate limit က ဒီလို လှိုင်းကို ထိန်းပေးတယ်
စရိတ်သက်သာအောင် — API တောင်းဆိုမှုတိုင်းက server အလုပ် (CPU၊ database) ကုန်တယ်။ Cloud မှာ ဒါက ပိုက်ဆံနဲ့ တိုက်ရိုက် ဆိုင်တယ်
အလွဲသုံးစားမှု တားဖို့ — password ကို တစ်စက္ကန့်ကို အကြိမ် တစ်သောင်း လိုက်စမ်းတဲ့ brute force တိုက်ခိုက်မှုမျိုးကို rate limit က အလိုလို နှေးကွေးသွားစေတယ်
မျှတအောင် — developer တစ်ယောက်တည်း API အကုန် ယူထားရင် ကျန်တဲ့သူတွေ သုံးလို့ မရတော့ဘူး

Rate limit ကို ဘယ်လို တိုင်းတာလဲဆိုတော့ နည်းလမ်း အမျိုးမျိုး ရှိတယ်။ အရိုးရှင်းဆုံးက “fixed window” — ဥပမာ “တစ်မိနစ်မှာ အကြိမ် ၆၀”။ 12:00:00 ကနေ 12:00:59 အတွင်း ၆၀ ကြိမ်၊ 12:01:00 ကျရင် ပြန် စတယ်။ နောက်တစ်နည်းက “token bucket” — ရေပုံးထဲမှာ token ၆၀ ရှိတယ်၊ တောင်းဆိုမှုတစ်ခါတိုင်းမှာ တစ်ခု ယူသွားတယ်၊ တစ်စက္ကန့်ကို တစ်ခု ပြန်ဖြည့်ပေးတယ်။ ပုံးထဲ token ကုန်သွားရင် စောင့်ရတယ်။ နာမည်ကြီး API တော်တော်များများ (GitHub, Twitter/X, OpenAI) က ဒီလိုမျိုး ပေါင်းစပ်နည်းတွေ သုံးတယ်။

ကန့်သတ်ချက် ကျော်သွားရင် ဘာဖြစ်လဲ။ Server က HTTP 429 (Too Many Requests) ဆိုတဲ့ status code ပြန်ပေးတယ်။ ပြီးတော့ “Retry-After: 60” ဆိုတဲ့ header ပါတယ် — “စက္ကန့် ၆၀ စောင့်ပြီးမှ ပြန်လာ” လို့ ပြောတာ။ တော်တော်များများက “X-RateLimit-Limit: 60” (အများဆုံး ဘယ်လောက်)၊ “X-RateLimit-Remaining: 0” (ကျန်တာ ဘယ်လောက်) ဆိုတဲ့ header တွေလည်း ထည့်ပေးတယ် — ကိုယ့် quota ဘယ်လောက် ကျန်လဲ ကြိုသိရတာပေါ့။

သာမန် user တစ်ယောက်အနေနဲ့ rate limit နဲ့ တွေ့ရတဲ့ အဖြစ်အများဆုံးက login form တွေ။ Password မှားပြီး ခဏခဏ နှိပ်နေရင် “too many attempts, try again in 5 minutes” ဆိုပြီး ပိတ်ခံရတယ် — ဒါ rate limiting ပဲ။ စိတ်မညစ်နဲ့၊ ဒါက မင်းကို ကာကွယ်ပေးနေတာ။ တကယ်လို့ hacker က မင်း account ကို brute force နဲ့ ထိုးဖောက်နေရင်လည်း ဒီစနစ်ကပဲ တားပေးနေတာလေ။

ကိုယ်တိုင် code ရေးပြီး API ခေါ်တဲ့သူဆိုရင် rate limit ကို လေးစားရမယ်။ လက်တွေ့ နည်းလမ်းတွေ —

429 ရရင် ချက်ချင်း ပြန်မခေါ်နဲ့။ Retry-After ဖတ်၊ ပြီးမှ exponential backoff (၁ စက္ကန့်၊ ၂ စက္ကန့်၊ ၄ စက္ကန့်…) နဲ့ ပြန်ကြိုးစား
ထပ်ခါထပ်ခါ တောင်းနေတဲ့ data ကို cache လုပ်။ တစ်မိနစ်မှာ အကြိမ် ၆၀ တောင်းမယ့်အစား တစ်ခါတောင်းပြီး သိမ်းထား
တကယ်လိုအပ်တာထက် ပိုမတောင်းနဲ့။ GraphQL လို “လိုတဲ့ field ပဲ တောင်း” လို့ ရတဲ့ API ဆို အဲဒါ သုံး
API key တစ်ခုတည်းနဲ့ အလုပ် အများကြီး လုပ်မယ့်အစား key ခွဲတာ၊ plan မြှင့်တာ စဉ်းစား

စိတ်ဝင်စားစရာကောင်းတာက rate limiting နဲ့ DDoS ကာကွယ်မှုရဲ့ ဆက်စပ်မှုပဲ။ DDoS ဆိုတာ လူအတုထောင်ပေါင်းနဲ့ server ကို ဝိုင်းတိုက်တာ — rate limiting က ဒီတိုက်ခိုက်မှုကို ပထမတန်း ကာကွယ်ရေးအနေနဲ့ နှေးကွေးသွားစေတယ်။ ဒါပေမယ့် rate limit တစ်ခုတည်းနဲ့ မလုံလောက်ဘူး၊ ဒါကြောင့် Cloudflare လို service တွေက တခြား နည်းလမ်းတွေနဲ့ တွဲသုံးတယ်။

နောက်တစ်ခါ “please try again later” ဆိုတဲ့ စာမျက်နှာ တွေ့ရင် စိတ်မဆိုးနဲ့တော့။ အဲဒါ server က မင်းကို ရန်လုပ်နေတာ မဟုတ်ဘူး — လူတိုင်းအတွက် မျှမျှတတ ဖြစ်အောင် တံခါးဝက ထိန်းပေးနေတဲ့ လုံခြုံရေးဝန်ထမ်းတစ်ယောက်ပဲ။ ATM က တစ်နေ့စာ ကန့်သတ်ထားသလိုမျိုး၊ ကန့်သတ်ချက်ရှိမှ စနစ်က ရေရှည်တည်တံ့တာ။ 🙂

===