রেট লিমিটিং কী?
রেট লিমিটিং (Rate Limiting) হলো একটি কৌশল যেখানে কোনো নির্দিষ্ট সময়সীমার মধ্যে একটি ক্লায়েন্ট (ইউজার, আইপি, অ্যাপ্লিকেশন) কতগুলো রিকোয়েস্ট করতে পারবে তা নিয়ন্ত্রণ করা হয়।
সহজ ভাষায়:
একটি রেস্টুরেন্টে একবারে কতজন গ্রাহক ঢুকতে পারবেন, তা নিয়ন্ত্রণ করা। খুব বেশি গ্রাহক এলে বাইরে লাইনে দাঁড়াতে বলেন।
[ক্লায়েন্ট]
|
↓ (রিকোয়েস্ট)
┌─────────────┐
│ রেট লিমিটার │ ← "তুমি ইতিমধ্যে ১০০টি রিকোয়েস্ট করে ফেলেছ"
└──────┬──────┘
↓
┌─────────────┐
│ API │ ← ২০০ ওকে, ৪২৯ টু মেনি রিকোয়েস্টস
│ সার্ভার │
└─────────────┘
কেন রেট লিমিটিং প্রয়োজন?
| কারণ | ব্যাখ্যা |
|---|---|
| ডিনায়েল অফ সার্ভিস (DoS) আক্রমণ প্রতিরোধ | একজন ম্যালিসিয়াস ইউজার সিস্টেম ক্র্যাশ করতে পারে |
| রিসোর্সের ন্যায্য বন্টন | একজন ইউজার সব রিসোর্স নিয়ে নেবে না |
| খরচ নিয়ন্ত্রণ | API খরচ বাঁচায় (যেমন: পেইড API-র কোটা) |
| সিস্টেম স্থিতিশীল রাখা | ব্যাকএন্ড সিস্টেম ওভারলোড হওয়া থেকে বাঁচায় |
| ব্যবহারিক নীতি প্রয়োগ | ফ্রিমিয়াম মডেলে ফ্রি ইউজারের সীমা নির্ধারণ |
রেট লিমিটিং এর প্রকারভেদ
১. ইউজার-বেসড লিমিটিং
- নির্দিষ্ট ইউজার আইডি বা এপিআই কী অনুযায়ী লিমিট
- উদাহরণ: ফ্রি টায়ার → ১০০ রিকোয়েস্ট/ঘন্টা
২. আইপি-বেসড লিমিটিং
- ক্লায়েন্টের আইপি অ্যাড্রেস অনুযায়ী লিমিট
- উদাহরণ: একটি আইপি থেকে ১০০০ রিকোয়েস্ট/দিন
৩. এন্ডপয়েন্ট-বেসড লিমিটিং
- ভিন্ন ভিন্ন এন্ডপয়েন্টের জন্য ভিন্ন লিমিট
- উদাহরণ: POST /login → ৫ রিকোয়েস্ট/মিনিট, GET /posts → ১০০০/মিনিট
৪. জিও-বেসড লিমিটিং
- ভৌগোলিক অবস্থান অনুযায়ী আলাদা লিমিট
রেট লিমিটিং অ্যালগরিদম
১. টোকেন বাকেট (Token Bucket)
কীভাবে কাজ করে:
একটি বালতিতে নির্দিষ্ট হারে টোকেন জমে। রিকোয়েস্ট এলে একটি টোকেন খরচ হয়। টোকেন না থাকলে রিকোয়েস্ট ব্লক হয়।
[টোকেন জমার হার: ১০/সেকেন্ড]
↓
┌─────────────┐
│ বালতি │ ← ক্যাপাসিটি: ১০০ টোকেন
│ 🪙🪙🪙🪙🪙 │
└──────┬──────┘
↓ (প্রতি রিকোয়েস্টে ১ টোকেন)
[ক্লায়েন্ট]
| সুবিধা | অসুবিধা |
|---|---|
| সহজ, মেমরি কম নেয় | বালতির সাইজ ও রেট টিউন করা জটিল |
| শর্ট-টাইম বার্স্ট হ্যান্ডেল করতে পারে | দুটি ভ্যারিয়েবল মনে রাখতে হয় |
| শিল্পে সবচেয়ে বেশি ব্যবহৃত | - |
২. লিকি বাকেট (Leaky Bucket)
কীভাবে কাজ করে:
রিকোয়েস্ট একটি কিউতে জমে, নির্দিষ্ট হারে প্রসেস হয়। কিউ ফুল্লে রিকোয়েস্ট ড্রপ হয়।
[আগত রিকোয়েস্ট] → [কিউ] → [কনস্ট্যান্ট রেটে আউটপুট]
↑
(কিউ ফুল্লে ড্রপ)
| সুবিধা | অসুবিধা |
|---|---|
| আউটপুট রেট কনস্ট্যান্ট | বার্স্ট হ্যান্ডেল করতে পারে না |
| ব্যাকএন্ড প্রটেক্ট করতে ভালো | কিউর জন্য মেমরি দরকার |
৩. ফিক্সড উইন্ডো কাউন্টার (Fixed Window Counter)
কীভাবে কাজ করে:
সময়কে নির্দিষ্ট উইন্ডোতে ভাগ করে (যেমন: ১ মিনিট)। প্রতিটি উইন্ডোতে কাউন্ট রাখা হয়।
মিনিট ১: ████████ (৮০ রিকোয়েস্ট) ✅
মিনিট ২: ██████████ (১০০ রিকোয়েস্ট) ✅
মিনিট ৩: ██████████████ (১৬০ রিকোয়েস্ট) ❌ লিমিট ১০০ ক্রস
| সুবিধা | অসুবিধা |
|---|---|
| মেমরি কম লাগে | উইন্ডোর প্রান্তে বার্স্ট হতে পারে (রিসেটের সময়) |
| সহজ | - |
৪. স্লাইডিং উইন্ডো লগ (Sliding Window Log)
কীভাবে কাজ করে:
প্রতিটি রিকোয়েস্টের টাইমস্ট্যাম্প লগে রাখা হয়। যখন নতুন রিকোয়েস্ট আসে, তখন গত N সময়ের মধ্যে কতগুলো রিকোয়েস্ট হয়েছে তা কাউন্ট করা হয়।
টাইমলাইন: --|--|--|--|--|--|--|--|-->
রিকোয়েস্ট: x x x x x x
^ ^
| |
গত ১ মিনিট বর্তমান
(৪টি রিকোয়েস্ট) (আরো ২টি)
লিমিট ৫ →
| সুবিধা | অসুবিধা |
|---|---|
| খুব সঠিক | অনেক মেমরি লাগে (লগ রাখতে হয়) |
| প্রান্তের বার্স্ট সমস্যা নেই | - |
৫. স্লাইডিং উইন্ডো কাউন্টার (Sliding Window Counter)
কীভাবে কাজ করে:
ফিক্সড উইন্ডো + স্লাইডিং উইন্ডোর হাইব্রিড। বর্তমান উইন্ডোতে ওভারল্যাপিং অংশের অনুপাত ধরে কাউন্ট করা হয়।
[উইন্ডো ১] [উইন্ডো ২]
80 40
└──────┬──────┘
বর্তমান পজিশন (১০ সেকেন্ড)
কাউন্ট = 80*0.5 + 40 = 80
| সুবিধা | অসুবিধা |
|---|---|
| প্রায় সঠিক, লগ রাখে না | একটু জটিল |
| ফিক্সড উইন্ডোর চেয়ে ভালো | - |
অ্যালগরিদম তুলনা
| অ্যালগরিদম | সঠিকতা | মেমরি | বার্স্ট সাপোর্ট | ব্যবহারের স্থান |
|---|---|---|---|---|
| টোকেন বাকেট | মাধ্যম | কম | হ্যাঁ | সাধারণ উদ্দেশ্য (AWS, Stripe) |
| লিকি বাকেট | মাধ্যম | মাধ্যম | না | ব্যাকএন্ড প্রটেকশন |
| ফিক্সড উইন্ডো | খারাপ | খুব কম | হ্যাঁ (প্রান্তে সমস্যা) | সহজ লিমিটিং |
| স্লাইডিং লগ | ভালো | বেশি | না | সঠিকতা জরুরি |
| স্লাইডিং কাউন্টার | ভালো | কম | হ্যাঁ | শিল্পে জনপ্রিয় (Cloudflare) |
Distributed Rate Limiting এর চ্যালেঞ্জ
| চ্যালেঞ্জ | সমাধান |
|---|---|
| একাধিক সার্ভার | Redis এর মতো কেন্দ্রীয় স্টোর ব্যবহার করুন |
| রেস কন্ডিশন | লুয়া স্ক্রিপ্ট বা রেডলক |
| লেটেন্সি | স্থানীয় রেট লিমিটার + প্রাইরিটি কিউ |
| স্কেলিং | শার্ডেড রেট লিমিটার (প্রতি শার্ডের লিমিট আলাদা) |
HTTP হেডার ও রেসপন্স কোড
রেট লিমিটিং তথ্য ক্লায়েন্টকে জানানোর জন্য স্ট্যান্ডার্ড হেডার:
| হেডার | ব্যাখ্যা |
|---|---|
X-RateLimit-Limit |
সময়সীমায় সর্বোচ্চ কত রিকোয়েস্ট |
X-RateLimit-Remaining |
এখনো কত রিকোয়েস্ট বাকি |
X-RateLimit-Reset |
কাউন্ট রিসেট হওয়ার সময় |
রেসপন্স কোড:
200 OK– রিকোয়েস্ট সফল429 Too Many Requests– লিমিট ক্রস করে ফেলেছেনRetry-Afterহেডার – কখন আবার চেষ্টা করবেন
বাস্তব উদাহরণ
গিটহাব API
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 58
X-RateLimit-Reset: 1700000000
লিমিট: ৬০ রিকোয়েস্ট/ঘন্টা (অনাথেনটিকেটেড)
লিমিট: ৫০০০ রিকোয়েস্ট/ঘন্টা (অথেনটিকেটেড)
টুইটার API
লিমিট: ৯০০ রিকোয়েস্ট/১৫ মিনিট (অ্যাপ)
লিমিট: ৩০০ রিকোয়েস্ট/৩ ঘন্টা (সার্চ)
স্ট্রাইপ API
লিমিট: ১০০ রিকোয়েস্ট/সেকেন্ড (প্রোডাকশন)
কৌশল: টোকেন বাকেট
বেস্ট প্র্যাকটিস ও টিপস
| টিপস | কেন গুরুত্বপূর্ণ |
|---|---|
| লেয়ারড রেট লিমিটিং | API গেটওয়ে + অ্যাপ্লিকেশন লেভেল → ডিফেন্স ইন ডেপথ |
| স্থিতিস্থাপকতা | রেট লিমিটার ডাউন থাকলেও সার্ভিস চালু রাখার ব্যবস্থা (সার্কিট ব্রেকার) |
| গ্রানুলারিটি | বিভিন্ন এন্ডপয়েন্টের জন্য আলাদা লিমিট (POST /login কম, GET / কিছু বেশি) |
| মনিটরিং | রেট লিমিট হিট হলে অ্যালার্ট, ক্লায়েন্টদের নোটিফাই করুন |
| সফট লিমিট | ৭০% হিটলে প্রি-ওয়ার্নিং দিন |
কখন রেট লিমিটিং ব্যবহার করবেন
করবেন:
- পাবলিক API
- লগইন এন্ডপয়েন্ট (ব্রুট ফোর্স প্রতিরোধ)
- রিসোর্স-ইনটেনসিভ অপারেশন (ভিডিও প্রসেসিং)
- পাসওয়ার্ড রিসেট
করবেন না:
- অভ্যন্তরীণ মাইক্রোসার্ভিস (সার্কিট ব্রেকার ভালো)
- খুব কম লেটেন্সি প্রয়োজন (অতিরিক্ত ওভারহেড)
সারাংশ চিটশিট
| যদি চান | তাহলে ব্যবহার করুন |
|---|---|
| সহজ, দ্রুত, শর্ট বার্স্ট সাপোর্ট | টোকেন বাকেট |
| ব্যাকএন্ড পুরোপুরি প্রটেক্ট করতে | লিকি বাকেট |
| অনেক জটিলতা ছাড়া ঠিকঠাক কাজ | স্লাইডিং উইন্ডো কাউন্টার |
| একদম সঠিক হিসাব (সামান্য ট্রেডঅফ সহ) | স্লাইডিং লগ |