Rate Limiting (রেট লিমিটিং)
- ●Rate limiting একজন ব্যবহারকারীকে নির্দিষ্ট সময়ে কতগুলো request পাঠাতে পারবে, তা সীমিত করে।
- ●এটা server-কে অতিরিক্ত চাপ, abuse আর DDoS আক্রমণ থেকে রক্ষা করে।
- ●জনপ্রিয় algorithm — Token Bucket, Leaky Bucket, Fixed/Sliding Window।
সমস্যাটা কী?
ধরো একজন ব্যবহারকারী (বা কোনো খারাপ bot) সেকেন্ডে হাজার হাজার request পাঠাচ্ছে। এতে server-এর সব শক্তি ওই একজনের পেছনে চলে যাবে, আর বাকি সব ব্যবহারকারী service পাবে না।
সমাধান: প্রত্যেককে একটা সীমা বেঁধে দাও — "তুমি প্রতি মিনিটে সর্বোচ্চ ১০০টা request পাঠাতে পারবে"। এটাই Rate Limiting।
Rate Limiting হলো — নির্দিষ্ট সময়ে একজন client কতগুলো request পাঠাতে পারবে, তার একটা সীমা নির্ধারণ। সীমা পেরোলে request আটকে দেওয়া হয় (সাধারণত 429 Too Many Requests error দিয়ে)।
বুফেতে নিয়ম থাকে — একবারে এক প্লেট। তুমি একসাথে দশ প্লেট নিয়ে গেলে বাকিদের জন্য কিছু থাকবে না। rate limiting ঠিক তেমন — সবাই যেন ন্যায্য ভাগ পায়।
কেন দরকার?
- Abuse ও DDoS রোধ — কেউ যেন ইচ্ছাকৃতভাবে server ডুবিয়ে না দেয়।
- খরচ নিয়ন্ত্রণ — অপ্রয়োজনীয় request মানে অপ্রয়োজনীয় খরচ।
- ন্যায্যতা — একজন যেন সবার ভাগ খেয়ে না ফেলে।
- API রক্ষা — তোমার public API অন্যরা যেন অপব্যবহার না করে।
নিজে চালিয়ে দেখো
বারবার request পাঠাও — দেখো token শেষ হলে কীভাবে request block হয়। তারপর token যোগ করে আবার চালাও:
জনপ্রিয় Algorithm
১. Token Bucket
একটা বালতিতে নির্দিষ্ট হারে token জমা হয়। প্রতিটা request একটা token খরচ করে। token থাকলে পাস, না থাকলে block। সুবিধা: অল্প সময়ের জন্য burst (হঠাৎ অনেক request) সামলাতে পারে।
২. Leaky Bucket
request একটা বালতিতে জমা হয় আর নির্দিষ্ট সমান গতিতে বেরোয় (যেন ফুটো বালতি)। ট্রাফিক একদম মসৃণ রাখে।
৩. Fixed Window Counter
প্রতি নির্দিষ্ট সময়ে (যেমন প্রতি মিনিটে) একটা গণনা — "এই মিনিটে ১০০টা হয়ে গেছে, আর নয়"। সহজ, কিন্তু window-এর সীমানায় হঠাৎ দ্বিগুণ চাপ পড়তে পারে।
৪. Sliding Window
চলমান সময়ের জানালা ধরে গণনা করে — Fixed Window-এর সীমানা সমস্যা এড়ায়। বেশি নিখুঁত।
| Algorithm | বিশেষত্ব |
|---|---|
| Token Bucket | burst অনুমতি দেয় |
| Leaky Bucket | মসৃণ, সমান গতি |
| Fixed Window | সহজ, কম নিখুঁত |
| Sliding Window | নিখুঁত, একটু জটিল |
ইন্টারভিউতে "rate limiter ডিজাইন করো" একটা খুব কমন প্রশ্ন। সাধারণত Token Bucket দিয়ে শুরু করা ভালো — এটা সহজ আর burst সামলাতে পারে। তারপর distributed system-এ এই counter কোথায় রাখবে (যেমন Redis-এ) সেটা নিয়ে কথা বলো।
বাস্তব উদাহরণ
Twitter/X, GitHub-এর মতো প্রায় সব বড় API-ই rate limit দেয় — যেমন "প্রতি ঘণ্টায় ৫০০০ request"। সীমা পেরোলে তারা 429 Too Many Requests ফেরত দেয় আর বলে দেয় কখন আবার চেষ্টা করতে পারবে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Rate limiting-এর মূল উদ্দেশ্য কী?
2. Token Bucket algorithm-এর বিশেষত্ব কী?