ডিজাইন ডিপ ডাইভ (Design Deep Dive)
উচ্চ-স্তরের আর্কিটেকচার নির্ধারণের পরে, এখন আমরা নিচের বিষয়গুলো গভীরভাবে আলোচনা করব:
- রেট লিমিটিং রুলস (Rate limiting rules)
- থ্রোটল হওয়া রিকোয়েস্টের হ্যান্ডেলিং (Exceeding the rate limit)
- বিতরণকৃত পরিবেশে রেট লিমিটার (Rate limiter in a distributed environment)
- পারফরম্যান্স অপ্টিমাইজেশন (Performance optimization)
- মনিটরিং (Monitoring)
রেস কন্ডিশন (Race Condition)
বিতরণকৃত পরিবেশে রেট লিমিটার ব্যবহারের সবচেয়ে বড় সমস্যা হলো রেস কন্ডিশন (race condition)।
চিত্র ১৪ (Figure 14) — দুটি রিকোয়েস্ট একসাথে কাউন্টার পড়ে একই সময়ে আপডেট করলে রেস কন্ডিশন তৈরি হয়।
ধরা যাক, কাউন্টারের মান ৩। দুটি রিকোয়েস্ট একসাথে কাউন্টার পড়ে (দুটোই ৩ দেখতে পায়), তারপর দুটোই check_and_increment করে কাউন্টারকে ৪ করে। কিন্তু আসলে কাউন্টার ৫ হওয়া উচিত ছিল।
সমাধান:
- Lua স্ক্রিপ্ট (Lua script): Redis-এ অ্যাটমিক অপারেশন নিশ্চিত করে
- সর্টেড সেট ডেটা স্ট্রাকচার (Sorted sets in Redis): অ্যাটমিক লগ স্টোরেজ
সিঙ্ক্রোনাইজেশন ইস্যু (Synchronization Issue)
একাধিক রেট লিমিটার সার্ভার ব্যবহার করলে সিঙ্ক্রোনাইজেশনের সমস্যা দেখা দেয়।
চিত্র ১৫ (Figure 15) — বাম দিক: সরল রাউটিং (Client 1 → Rate Limiter 1, Client 2 → Rate Limiter 2); ডান দিক: ক্রস রাউটিং সমস্যা।
ডান দিকের চিত্রে দেখা যাচ্ছে, ক্লায়েন্ট ১ রেট লিমিটার ১ ও ২ উভয়কে রিকোয়েস্ট পাঠাচ্ছে। রেট লিমিটার ১ ও ২ আলাদা থাকলে তারা একে অপরের কাউন্টার জানে না, ফলে রেট লিমিট বাইপাস হয়।
সমাধান:
- Sticky session: একই ক্লায়েন্টকে সবসময় একই রেট লিমিটারে পাঠানো (তবে এটি স্কেলেবল নয়)
- Centralized data store (Redis): সব রেট লিমিটার একই Redis থেকে পড়ে
চিত্র ১৬ (Figure 16) — Client 1 ও Client 2 দুটি আলাদা রেট লিমিটারে যায়, কিন্তু উভয়ই একই Redis শেয়ার করে — কাউন্টার সিঙ্ক থাকে।
পারফরম্যান্স অপ্টিমাইজেশন (Performance Optimization)
বড় পরিসরে রেট লিমিটার ডিপ্লয় করার সময় দুটি বিষয়ে উন্নতি করা সম্ভব:
১. মাল্টি-ডেটাসেন্টার সেটআপ (Multi-data center setup)
চিত্র ১৭ (Figure 17) — ব্যবহারকারী ইউরোপে থাকলে নিকটতম ডেটাসেন্টারে রাউট করা হয়, লেটেন্সি কমে।
লেটেন্সি সমস্যা কমাতে ট্রাফিক নিকটতম এজ সার্ভারে রাউট করা হয়। বিভিন্ন দেশে ডেটাসেন্টার থাকলে ব্যবহারকারীর অভিজ্ঞতা ভালো হয়।
২. ইভেন্টুয়াল কনসিস্টেন্সি মডেল (Eventual consistency model)
রেট লিমিটার সার্ভারগুলোর মধ্যে ডেটা সিঙ্ক করতে ইভেন্টুয়াল কনসিস্টেন্সি মডেল ব্যবহার করা যায়। এটি স্ট্রিক্ট কনসিস্টেন্সির তুলনায় দ্রুত।
মনিটরিং (Monitoring)
রেট লিমিটার ইনস্টল করার পরে, মনিটরিং করা দরকার যাতে নিশ্চিত করা যায়:
- রেট লিমিটিং অ্যালগরিদম কার্যকর কিনা
- রেট লিমিটিং রুলগুলো কার্যকর কিনা
যদি রুলগুলো অনেক বেশি কঠোর হয়, তাহলে বৈধ রিকোয়েস্টগুলোও বাতিল হতে পারে। নিয়মিত মনিটরিং করে রুলগুলো অ্যাডজাস্ট করুন।