উচ্চ-স্তরের আর্কিটেকচার (High-level Architecture)

রেট লিমিটিং অ্যালগরিদমের মূল প্রশ্ন হলো: কাউন্টার কোথায় সংরক্ষণ করব?

ডাটাবেস ব্যবহার করা ঠিক নয় কারণ ডিস্ক অ্যাক্সেস ধীর। আমরা ইন-মেমোরি ক্যাশ (in-memory cache) ব্যবহার করি কারণ এটি দ্রুত এবং টাইম-বেসড এক্সপায়ারেশন পলিসি সাপোর্ট করে। Redis হলো রেট লিমিটিং-এর জন্য সবচেয়ে জনপ্রিয় বিকল্প। Redis দুটি কমান্ড অফার করে:

• INCR: মেমোরিতে সংরক্ষিত কাউন্টার ১ বাড়ায়।
• EXPIRE: কাউন্টারের জন্য একটি টাইমআউট সেট করে। টাইমআউটের পরে কাউন্টার স্বয়ংক্রিয়ভাবে মুছে যায়।

চিত্র ১২ (Figure 12) — ক্লায়েন্ট → রেট লিমিটার মিডলওয়্যার (Hexagonal) → API সার্ভার এবং Redis।

উচ্চ-স্তরে সিস্টেমটি কীভাবে কাজ করে:

1. ক্লায়েন্ট রেট লিমিটার মিডলওয়্যারে একটি রিকোয়েস্ট পাঠায়।
2. রেট লিমিটার মিডলওয়্যার Redis থেকে কাউন্টার নিয়ে আসে এবং লিমিট পৌঁছে গেছে কিনা পরীক্ষা করে।
   • লিমিট পৌঁছে গেলে: রিকোয়েস্ট প্রত্যাখ্যান করা হয়।
   • লিমিট না পৌঁছালে: রিকোয়েস্ট API সার্ভারে পাঠানো হয়। Redis কাউন্টার বাড়ানো হয়।

সম্পূর্ণ রেট লিমিটার ফ্লো (Full Rate Limiter Architecture)

নিচে একটি সম্পূর্ণ রেট লিমিটার আর্কিটেকচার দেখানো হয়েছে — ক্যাশড রুলস, Workers, Redis কাউন্টার, এবং রিকোয়েস্ট ড্রপ/কিউ করার অপশন সহ:

চিত্র ১৩ (Figure 13) — সম্পূর্ণ রেট লিমিটার আর্কিটেকচার: ক্লায়েন্ট → মিডলওয়্যার → (ক্যাশড রুলস / API সার্ভার / Redis / ড্রপ অথবা কিউ)।

উপাদানগুলোর ব্যাখ্যা:

• Rules (নিয়ম): রেট লিমিটিং রুলগুলো ডিস্কে সংরক্ষণ করা হয়।
• Workers: Workers পর্যায়ক্রমে ডিস্ক থেকে রুল টেনে ক্যাশে রাখে।
• Cache (ক্যাশ): ক্যাশড রুলস দ্রুত পড়া যায়।
• Redis: রিকোয়েস্ট কাউন্টার সংরক্ষণ করে।
• Option 1 (Drop): অতিরিক্ত রিকোয়েস্ট সরাসরি বাদ দেওয়া হয়।
• Option 2 (Queue): অতিরিক্ত রিকোয়েস্ট একটি মেসেজ কিউতে রাখা হয় পরে প্রক্রিয়ার জন্য।
• 429 Response: থ্রোটল হলে ক্লায়েন্টকে HTTP 429 কোড ফেরত দেওয়া হয়।