Project: Client တစ်ခုချင်းစီအတွက် Rate Limiter Service

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

global token bucket တစ်ခုတည်းဟာ server ကို overall overload ကနေ ကာကွယ်ပေးပေမယ့် fairness ပြဿနာ ရှိတယ် - client တစ်ယောက်က request burst ပို့ပြီး shared bucket ကို ဖုန်းကုန်သွားစေရင် ကျန် client တွေအားလုံးလည်း ဘာမှမကျူးလွန်ဘဲနဲ့ throttle ခံရတယ်။ ဒီပြဿနာကို ဖြေရှင်းဖို့ client တစ်ခုချင်းစီကို API key ဒါမှမဟုတ် user ID လို identifier နဲ့ key ထားတဲ့ သီးသန့် token bucket ပေးလိုက်ရင် bucket တွေက အချင်းချင်း သက်ဆိုင်မှုမရှိဘဲ refill/drain ဖြစ်တယ် - client noisy တစ်ယောက်ဟာ သူ့ quota ကိုပဲ ကုန်စေနိုင်တော့တယ်။ implementation အနေနဲ့ natural ဆုံးကတော့ client_id ကနေ TokenBucket instance ဆီ ချိတ်ထားတဲ့ dict တစ်ခု ဖြစ်ပြီး ဒီ client ကို ပထမဆုံးအကြိမ် တွေ့တဲ့အခါမှသာ lazily ဖန်တီးလိုက်ရင် ဘယ်တော့မှ မလာနိုင်တဲ့ client တွေအတွက် bucket ကြိုတင်ဖန်တီးစရာ မလိုတော့ဘူး။ တကယ့် design trade-off ကတော့ ဒီ dict က ဘယ်မှာနေထိုင်လဲဆိုတဲ့ အချက်ဖြစ်တယ် - process တစ်ခုတည်းရဲ့ memory ထဲမှာ သိမ်းထားတာက ရိုးရှင်းပြီး မြန်ပေမယ့် client တစ်ယောက်ရဲ့ request အားလုံးက server instance တစ်ခုတည်းကို ဝင်တဲ့အခါမှသာ အလုပ်လုပ်တယ်။ load balancer နောက်ကွယ်မှာ instance အများကြီးဆီ scale ဖြစ်သွားတဲ့ အခိုက်အတန့်ကနေစပြီး per-client state ကို Redis (atomic increment/expire operation နဲ့) လို shared store ဆီ ရွှေ့ရတော့တယ်၊ မရွှေ့ရင် client တစ်ယောက်ရဲ့ request တွေဟာ instance တစ်ခုစီက bucket ကို ဗလာဖြစ်နေတယ်လို့ ထင်နေတဲ့ instance တွေကို ပျံ့နှံ့ကျဲသွားလို့ ရသင့်ထက်ပိုတဲ့ token ရသွားနိုင်တယ်။

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

ဒါဟာ Tutorial Platform က public API မှာ လိုအပ်လာမယ့် rate limiting ကို model လုပ်တာဖြစ်တယ် - ဥပမာ third-party integration ဒါမှမဟုတ် mobile app ကို lesson content ပေးနေတဲ့ endpoint တစ်ခု။ API key တစ်ခုချင်းစီက သူ့ bucket ကို ရရှိတယ်ဆိုရင် integration partner တစ်ယောက်ကနေ runaway script တစ်ခုက ကျန် endpoint အတူတူသုံးနေတဲ့ learner တွေရဲ့ response time ကို ဆိုးရွားစေလို့ မရနိုင်ဘူး။ အခုတော့ platform ဟာ Next.js deployment တစ်ခုတည်းဖြစ်နေတာမို့ memory ထဲသိမ်းထားတဲ့ dict က တရားဝင် stopgap တစ်ခုအဖြစ် သုံးလို့ရသေးတယ်၊ server instance တစ်ခုထက်ပိုပြီး scale ဖြစ်တဲ့အခိုက်အတန့်ကနေစပြီးတော့ (ဥပမာ Vercel region အများကြီး) ဒီ memory-based version ဟာ instance တစ်ခုချင်းစီမှာ limit ကို silently under-enforce လုပ်သွားလိမ့်မယ် - ဒါကပဲ bucket state ကို Redis ဆီ ရွှေ့ဖို့ trigger ဖြစ်တယ်။

• Client တစ်ခုချင်းစီအတွက် token bucket တစ်ခုစီ ရှိသင့်တယ် - global bucket တစ်ခုတည်းဆိုရင် abusive client တစ်ယောက်က ကျန်သူများကို throttle ဖြစ်စေနိုင်တယ်။
• Client တစ်ယောက်ရဲ့ request ကို ပထမဆုံးအကြိမ်လက်ခံတဲ့အခါမှသာ bucket ကို lazily ဖန်တီးတယ် - ဘယ်တော့မှ မလာမယ့် client တွေအတွက် memory မဖြုန်းတော့ဘူး။
• Memory ထဲမှာသိမ်းထားတဲ့ per-client state ဟာ server instance တစ်ခုတည်းမှာပဲ အလုပ်လုပ်တယ် - instance အများကြီးရှိတဲ့ deployment တွေမှာတော့ Redis လို shared store လိုအပ်တယ်။

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

import time


class TokenBucket:
    def __init__(self, capacity: int, refill_rate: float):
        self.capacity = capacity
        self.refill_rate = refill_rate  # tokens per second
        self.tokens = float(capacity)
        self.last_refill = time.monotonic()

    def _refill(self):
        now = time.monotonic()
        elapsed = now - self.last_refill
        self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
        self.last_refill = now

    def allow(self) -> bool:
        self._refill()
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False


class RateLimiterService:
    def __init__(self, capacity: int, refill_rate: float):
        self.capacity = capacity
        self.refill_rate = refill_rate
        self._buckets = {}  # client_id -> TokenBucket

    def _get_bucket(self, client_id: str) -> TokenBucket:
        if client_id not in self._buckets:
            self._buckets[client_id] = TokenBucket(self.capacity, self.refill_rate)
        return self._buckets[client_id]

    def allow_request(self, client_id: str) -> bool:
        return self._get_bucket(client_id).allow()


if __name__ == "__main__":
    limiter = RateLimiterService(capacity=3, refill_rate=0)  # no refill during demo

    print("Client A (bursty, sends 5 requests):")
    for i in range(5):
        print(f"  request {i + 1}: {'allowed' if limiter.allow_request('client-a') else 'THROTTLED'}")

    print("Client B (sends 2 requests):")
    for i in range(2):
        print(f"  request {i + 1}: {'allowed' if limiter.allow_request('client-b') else 'THROTTLED'}")

Client A ရဲ့ ပထမဆုံး request 3 ခုက allowed ဖြစ်ပြီး bucket ဗလာဖြစ်သွားတဲ့အခါ ကျန် 2 ခုက THROTTLED ဖြစ်သွားတယ်၊ Client B ကတော့ သူ့ဟာသူ သီးသန့် bucket ရှိနေတာမို့ request 2 ခုစလုံး allowed ဖြစ်တယ်။

Wikipedia — Token bucket — System Design