Rate Limiting
সিস্টেমের সিকিউরিটি এবং অ্যাভেইল্যাবিলিটি নিশ্চিত করার জন্য Rate Limiting একটি অত্যন্ত গুরুত্বপূর্ণ কৌশল। এটি নিয়ন্ত্রণ করে যে একজন ইউজার বা একটি সার্ভিস নির্দিষ্ট সময়ে কতগুলো রিকোয়েস্ট পাঠাতে পারবে।
1. কেন Rate Limiting প্রয়োজন?
- Preventing Abuse: হ্যাকারদের ব্রুট-ফোর্স (Brute-force) অ্যাটাক বা বটদের হাত থেকে রক্ষা পাওয়া।
- Preventing DDoS: একসাথে অসংখ্য রিকোয়েস্ট পাঠিয়ে সার্ভার ডাউন করে দেওয়া রোধ করা।
- Cost Control: যদি আপনি থার্ড-পার্টি পেইড এপিআই ব্যবহার করেন, তবে রিকোয়েস্ট লিমিট করে খরচ নিয়ন্ত্রণ করা।
- Fairness: যেন একজন ইউজার বেশি লোড দিয়ে অন্যদের জন্য সিস্টেম স্লো না করে দেয়।
2. জনপ্রিয় Rate Limiting অ্যালগরিদম
Token Bucket
একটি ভার্চুয়াল বালতি (Bucket) থাকে যাতে নির্দিষ্ট সংখ্যক টোকেন জমা হয়। প্রতিটি রিকোয়েস্টের জন্য একটি টোকেন খরচ হয়। যদি বালতি খালি থাকে, তবে রিকোয়েস্ট রিজেক্ট করা হয়।
- সুবিধা: এটি বড় ট্রাফিক বার্স্ট (Traffic Burst) হ্যান্ডেল করতে পারে।
Leaky Bucket
বালতিতে রিকোয়েস্ট জমা হয় এবং একটি নির্দিষ্ট গতিতে (Constant rate) নিচ দিয়ে ফুটো হয়ে সার্ভিস সার্ভারে যায়। বালতি পূর্ণ হয়ে গেলে নতুন রিকোয়েস্ট ফেলে দেওয়া হয়।
- সুবিধা: এটি আউটপুট ডিস্ট্রিবিউশন একদম স্মুথ রাখে।
Fixed Window Counter
সময়ের একটি নির্দিষ্ট ফ্রেম (যেমন ১ মিনিট) ধরে রিকোয়েস্ট কাউন্ট করা হয়। এক মিনিট শেষ হলেই কাউন্টার ০ হয়ে যায়।
- অসুবিধা: জানালার একদম শেষে এবং শুরুর মুহূর্তে বেশি রিকোয়েস্ট চলে আসতে পারে।
Sliding Window Log/Counter
এটি ফিক্সড উইন্ডোর উন্নত সংস্করণ যা সময়ের ফ্রেমকে একদম নির্ভুলভাবে ট্রাক করে এবং এজ-কেসগুলো সমাধান করে।
3. Rate Limiter কোথায় থাকে?
- Client Side: ক্লায়েন্ট নিজেই লিমিট সেট করে (সহজে বাইপাস করা যায়)।
- API Gateway: অধিকাংশ আধুনিক সিস্টেমে এপিআই গেটওয়ে বা রিভার্স প্রক্সিতে এটি থাকে।
- Service Side: সরাসরি অ্যাপ্লিকেশন কোডের ভেতরে।
CAUTION
যখন কোনো রিকোয়েস্ট লিমিট পার করে ফেলে, তখন সার্ভার সাধারণত HTTP 429 Too Many Requests স্ট্যাটাস কোড পাঠিয়ে দেয়। এটি ইউজারকে জানানো জরুরি যে তারা লিমিট ক্রস করেছে।