Rate limiting: token bucket, sliding window ও বানানোর উপায়
Rate limiting আপনার সার্ভিসকে অপব্যবহার, বাগ ও traffic spike থেকে রক্ষা করে। চার মূল algorithm এবং অনেক server জুড়ে চালানোর উপায় জানুন।
Rate limiter নির্দিষ্ট সময়ে একজন client কতগুলো request করতে পারবে তার সীমা বাঁধে। এটি অপব্যবহার ও brute-force login ঠেকায়, shared resource বাঁচায়, আর একজন গোলমেলে client-কে বাকিদের ক্ষতি করতে দেয় না।
কীসের ভিত্তিতে সীমা দেবেন
User ID, API key, IP address, বা মিশ্রণ। শুধু IP দুর্বল: অনেকে একই IP ভাগ করে, আর আক্রমণকারী IP বদলায়।
মূল algorithm
- Fixed window: প্রতি মিনিটে গুনে মিনিটের শেষে শূন্য করা। সহজ, কিন্তু সীমানার দুই পাশে burst হলে প্রায় দ্বিগুণ request ঢুকতে পারে।
- Sliding window: এখন থেকে গত ৬০ সেকেন্ডের request গোনা। মসৃণ ও নিখুঁত, কিন্তু বেশি memory লাগে।
- Token bucket: বালতিতে নির্দিষ্ট হারে token ভরে; প্রতি request একটি নেয়। বালতির আকার পর্যন্ত ছোট burst চলে, আর গড় হার স্থির থাকে। খুব জনপ্রিয়।
- Leaky bucket: request queue-তে ঢোকে আর নির্দিষ্ট হারে বের হয়। মসৃণ output, কিন্তু burst অপেক্ষা করে বা বাদ যায়।
অনেক server-এ চালানো
প্রতিটি server-এর memory-র counter যোগ হয় না। Redis-এর মতো shared দ্রুত store ব্যবহার করুন atomic operation দিয়ে (INCR সাথে expiry, বা Lua script), যাতে যাচাই ও আপডেট একসাথে হয়।
Client কী দেখবে
HTTP 429 Too Many Requests ফেরত দিন, সাথে Retry-After header এবং সীমা ও বাকি সংখ্যার header। Client তখন ঠিকভাবে পিছিয়ে যেতে পারে।
কোথায় বসাবেন
Edge বা API gateway-তে, যাতে খারাপ traffic আগেই বাদ যায়। Login ও password reset-এর মতো সংবেদনশীল কাজে আরও কড়া সীমা রাখুন।
আগে ঠিক করুন
Redis ডাউন থাকলে খোলা রাখবেন না বন্ধ? Plan অনুযায়ী আলাদা সীমা? Burst চলবে? এগুলো লিখে রাখুন।
মূল কথা: Redis-এ token bucket, user বা API key দিয়ে, 429 ও Retry-After সহ, একটি শক্ত ডিফল্ট।
System Design সিরিজের 11 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: Consistent hashing: server বাড়ালে সব নড়ে না কেন.
