হাই-লেভেল ডিজাইন প্রস্তাব করা এবং সম্মতি (buy-in) নেওয়া (Propose high-level design and get buy-in)

চলুন বিষয়টিকে সহজ রাখি এবং কমিউনিকেশনের জন্য একটি সাধারণ ক্লায়েন্ট-সার্ভার মডেল (client and server model) ব্যবহার করি।

রেট লিমিটার কোথায় রাখব? সাধারণ যুক্তিতে, আপনি একটি রেট লিমিটার ক্লায়েন্ট বা সার্ভার—যেকোনো এক সাইডে ইমপ্লিমেন্ট (implement) বা বসাতে পারেন।

• ক্লায়েন্ট-সাইড ইমপ্লিমেন্টেশন (Client-side implementation): সাধারণভাবে বলতে গেলে, রেট লিমিটিং প্রয়োগ করার জন্য ক্লায়েন্ট একটি অনির্ভরযোগ্য (unreliable) জায়গা, কারণ ক্ষতিকর ব্যক্তিরা (malicious actors) খুব সহজেই ক্লায়েন্ট রিকোয়েস্টগুলো জাল (forge) করতে পারে। তাছাড়া, ক্লায়েন্ট ইমপ্লিমেন্টেশনের ওপর আমাদের হয়তো কোনো নিয়ন্ত্রণও থাকে না।
• সার্ভার-সাইড ইমপ্লিমেন্টেশন (Server-side implementation): চিত্র ১-এ (Figure 1) সার্ভার-সাইডে বসানো একটি রেট লিমিটার দেখানো হয়েছে।

চিত্র ১ (Figure 1)

ক্লায়েন্ট এবং সার্ভার-সাইড ইমপ্লিমেন্টেশনের পাশাপাশি, এর একটি বিকল্প উপায়ও রয়েছে। এপিআই (API) সার্ভারগুলোতে রেট লিমিটার রাখার পরিবর্তে, আমরা একটি রেট লিমিটার মিডলওয়্যার (middleware) তৈরি করতে পারি, যা চিত্র ২-এর (Figure 2) মতো আপনার এপিআইগুলোতে আসা রিকোয়েস্টগুলোকে থ্রোটল বা নিয়ন্ত্রণ করে।

চিত্র ২ (Figure 2)

এই ডিজাইনে রেট লিমিটিং কীভাবে কাজ করে তা ব্যাখ্যা করার জন্য চলুন চিত্র ৩-এর (Figure 3) একটি উদাহরণ ব্যবহার করি। ধরুন, আমাদের এপিআই প্রতি সেকেন্ডে ২টি রিকোয়েস্ট অ্যালাউ করে, কিন্তু একজন ক্লায়েন্ট এক সেকেন্ডের মধ্যে সার্ভারে ৩টি রিকোয়েস্ট পাঠাল। প্রথম দুটি রিকোয়েস্ট এপিআই সার্ভারগুলোতে রাউট (route) বা পাঠিয়ে দেওয়া হবে। তবে, রেট লিমিটার মিডলওয়্যারটি তৃতীয় রিকোয়েস্টটিকে আটকে দেবে এবং একটি ‘HTTP status code 429’ রিটার্ন করবে। HTTP 429 রেসপন্স স্ট্যাটাস কোড নির্দেশ করে যে একজন ব্যবহারকারী খুব বেশি রিকোয়েস্ট পাঠিয়েছেন।

চিত্র ৩ (Figure 3)

ক্লাউড মাইক্রোসার্ভিস (Cloud microservices) [৪] বর্তমানে ব্যাপকভাবে জনপ্রিয় হয়ে উঠেছে এবং এগুলোতে রেট লিমিটিং সাধারণত ‘এপিআই গেটওয়ে’ (API gateway) নামক একটি কম্পোনেন্টের মধ্যে ইমপ্লিমেন্ট করা হয়। এপিআই গেটওয়ে হলো একটি ফুললি-ম্যানেজড সার্ভিস (fully managed service) যা রেট লিমিটিং, এসএসএল টার্মিনেশন (SSL termination), অথেনটিকেশন (authentication), আইপি হোয়াইটলিস্টিং (IP whitelisting), স্ট্যাটিক কনটেন্ট সার্ভিসিং ইত্যাদি সাপোর্ট করে। আপাতত, আমাদের শুধু এটুকু জানলেই চলবে যে এপিআই গেটওয়ে হলো এমন একটি মিডলওয়্যার যা রেট লিমিটিং সাপোর্ট করে।

একটি রেট লিমিটার ডিজাইন করার সময়, নিজেদের যে গুরুত্বপূর্ণ প্রশ্নটি করা উচিত তা হলো: রেট লিমিটারটি কোথায় ইমপ্লিমেন্ট করা উচিত—সার্ভার-সাইডে নাকি গেটওয়েতে? এর কোনো বাঁধাধরা বা নির্দিষ্ট উত্তর নেই। এটি নির্ভর করে আপনার কোম্পানির বর্তমান টেকনোলজি স্ট্যাক (technology stack), ইঞ্জিনিয়ারিং রিসোর্স, অগ্রাধিকার, লক্ষ্য ইত্যাদির ওপর। নিচে কিছু সাধারণ গাইডলাইন বা নির্দেশিকা দেওয়া হলো:

• আপনার বর্তমান টেকনোলজি স্ট্যাক মূল্যায়ন করুন, যেমন—প্রোগ্রামিং ভাষা, ক্যাশ সার্ভিস (cache service) ইত্যাদি। নিশ্চিত করুন যে আপনার বর্তমান প্রোগ্রামিং ভাষাটি সার্ভার-সাইডে রেট লিমিটিং ইমপ্লিমেন্ট করার জন্য যথেষ্ট কার্যকরী (efficient)।
• আপনার ব্যবসার প্রয়োজনের সাথে মানানসই রেট লিমিটিং অ্যালগরিদমটি চিহ্নিত করুন। আপনি যখন সার্ভার-সাইডে সবকিছু ইমপ্লিমেন্ট করেন, তখন অ্যালগরিদমের ওপর আপনার সম্পূর্ণ নিয়ন্ত্রণ থাকে। তবে, আপনি যদি কোনো থার্ড-পার্টি গেটওয়ে (third-party gateway) ব্যবহার করেন, তাহলে আপনার পছন্দ সীমিত হতে পারে।
• আপনি যদি এরই মধ্যে মাইক্রোসার্ভিস আর্কিটেকচার ব্যবহার করে থাকেন এবং ডিজাইনে অথেনটিকেশন, আইপি হোয়াইটলিস্টিং ইত্যাদি করার জন্য একটি এপিআই গেটওয়ে যুক্ত করে থাকেন, তবে আপনি সেই এপিআই গেটওয়েতেই একটি রেট লিমিটার যোগ করতে পারেন।
• নিজস্ব রেট লিমিটিং সার্ভিস তৈরি করতে সময় লাগে। একটি রেট লিমিটার তৈরি করার জন্য আপনার যদি পর্যাপ্ত ইঞ্জিনিয়ারিং রিসোর্স না থাকে, তবে কমার্শিয়াল (commercial) বা কেনা যায় এমন কোনো এপিআই গেটওয়ে ব্যবহার করাটাই ভালো বিকল্প।