রেট লিমিটার ডিজাইন করা (Design A Rate Limiter)

একটি নেটওয়ার্ক সিস্টেমে ক্লায়েন্ট বা সার্ভিসের পাঠানো ট্রাফিকের হার (rate of traffic) নিয়ন্ত্রণ করতে রেট লিমিটার (rate limiter) ব্যবহার করা হয়। এইচটিটিপি (HTTP) দুনিয়ায়, একটি রেট লিমিটার নির্দিষ্ট সময়ের মধ্যে ক্লায়েন্টের পাঠানো রিকোয়েস্টের সংখ্যা সীমিত করে। যদি এপিআই (API) রিকোয়েস্টের সংখ্যা রেট লিমিটারের নির্ধারিত সীমা (threshold) অতিক্রম করে, তবে অতিরিক্ত সমস্ত কল ব্লক বা আটকে দেওয়া হয়। নিচে এর কয়েকটি উদাহরণ দেওয়া হলো:

• একজন ব্যবহারকারী প্রতি সেকেন্ডে ২টির বেশি পোস্ট লিখতে পারবেন না।
• আপনি একই আইপি (IP) ঠিকানা থেকে দিনে সর্বোচ্চ ১০টি অ্যাকাউন্ট তৈরি করতে পারবেন।
• আপনি একই ডিভাইস থেকে সপ্তাহে ৫ বারের বেশি রিওয়ার্ড (reward) দাবি করতে পারবেন না।

এই অধ্যায়ে, আপনাকে একটি রেট লিমিটার ডিজাইন করতে বলা হয়েছে। ডিজাইন শুরু করার আগে, চলুন একটি এপিআই (API) রেট লিমিটার ব্যবহারের সুবিধাগুলো দেখে নিই:

• ডিনায়াল অফ সার্ভিস (Denial of Service বা DoS) অ্যাটাকের কারণে সৃষ্ট রিসোর্স স্টারভেশন (resource starvation - রিসোর্সের ঘাটতি) প্রতিরোধ করে [১]: বড় বড় টেক কোম্পানিগুলোর প্রকাশিত প্রায় সব এপিআই-তেই কোনো না কোনো ধরনের রেট লিমিটিং প্রয়োগ করা থাকে। উদাহরণস্বরূপ, টুইটার (Twitter) প্রতি ৩ ঘণ্টায় সর্বোচ্চ ৩০০টি টুইট করার সীমা নির্ধারণ করে দেয় [২]। গুগল ডকস (Google docs) এপিআই-তে রিড রিকোয়েস্টের জন্য ডিফল্ট লিমিট হলো: প্রতি ৬০ সেকেন্ডে প্রতি ব্যবহারকারীর জন্য ৩০০টি রিকোয়েস্ট [৩]। একটি রেট লিমিটার ইচ্ছাকৃত বা অনিচ্ছাকৃত—যেকোনো অতিরিক্ত কল ব্লক করার মাধ্যমে DoS অ্যাটাক প্রতিরোধ করে।
• খরচ কমানো (Reduce cost): অতিরিক্ত রিকোয়েস্ট সীমিত করার অর্থ হলো কম সার্ভার ব্যবহার করা এবং উচ্চ অগ্রাধিকারপ্রাপ্ত (high priority) এপিআইগুলোর জন্য বেশি রিসোর্স বরাদ্দ করা। যেসব কোম্পানি পেইড থার্ড-পার্টি এপিআই (paid third party APIs) ব্যবহার করে, তাদের জন্য রেট লিমিটিং অত্যন্ত গুরুত্বপূর্ণ। উদাহরণস্বরূপ, নিচের এক্সটার্নাল এপিআইগুলোর ক্ষেত্রে আপনাকে প্রতি-কলের (per-call basis) ওপর চার্জ দিতে হয়: ক্রেডিট চেক করা, পেমেন্ট করা, হেলথ রেকর্ড রিট্রিভ বা সংগ্রহ করা ইত্যাদি। খরচ কমানোর জন্য এ ধরনের কলের সংখ্যা সীমিত করা অপরিহার্য।
• সার্ভার ওভারলোডেড (overloaded) হওয়া রোধ করে: সার্ভারের লোড কমানোর জন্য, বট (bots) বা ব্যবহারকারীদের অসদাচরণের কারণে আসা অতিরিক্ত রিকোয়েস্টগুলোকে ফিল্টার করে বাদ দিতে রেট লিমিটার ব্যবহার করা হয়।

ধাপ ১ - সমস্যাটি বোঝা এবং ডিজাইনের পরিধি নির্ধারণ করা (Understand the problem and establish design scope)

রেট লিমিটিং বিভিন্ন অ্যালগরিদম ব্যবহার করে প্রয়োগ করা যেতে পারে, যার প্রত্যেকটিরই নিজস্ব সুবিধা ও অসুবিধা (pros and cons) রয়েছে। ইন্টারভিউয়ার এবং প্রার্থীর মধ্যকার কথোপকথনটি আমরা ঠিক কী ধরনের রেট লিমিটার তৈরি করার চেষ্টা করছি তা পরিষ্কার করতে সাহায্য করে।

প্রার্থী: আমরা কী ধরনের রেট লিমিটার ডিজাইন করতে যাচ্ছি? এটি কি ক্লায়েন্ট-সাইড (client-side) রেট লিমিটার নাকি সার্ভার-সাইড (server-side) এপিআই রেট লিমিটার? ইন্টারভিউয়ার: চমৎকার প্রশ্ন। আমরা সার্ভার-সাইড এপিআই রেট লিমিটারের ওপর ফোকাস করছি।

প্রার্থী: রেট লিমিটার কি আইপি (IP), ইউজার আইডি (user ID) নাকি অন্য কোনো বৈশিষ্ট্যের ওপর ভিত্তি করে এপিআই রিকোয়েস্ট থ্রোটল (throttle বা নিয়ন্ত্রণ) করবে? ইন্টারভিউয়ার: রেট লিমিটারটি এমনভাবে ফ্লেক্সিবল (flexible) হওয়া উচিত যাতে এটি বিভিন্ন ধরনের থ্রোটল রুলস (throttle rules) সাপোর্ট করতে পারে।

প্রার্থী: সিস্টেমের স্কেল (scale) বা আকার কেমন? এটি কি কোনো স্টার্টআপের জন্য তৈরি করা হচ্ছে, নাকি বিশাল ইউজার বেস (user base) থাকা বড় কোনো কোম্পানির জন্য? ইন্টারভিউয়ার: সিস্টেমটিকে অবশ্যই বিপুল সংখ্যক রিকোয়েস্ট হ্যান্ডেল করতে পারতে হবে।

প্রার্থী: সিস্টেমটি কি একটি ডিস্ট্রিবিউটেড এনভায়রনমেন্টে (distributed environment) কাজ করবে? ইন্টারভিউয়ার: হ্যাঁ।

প্রার্থী: রেট লিমিটারটি কি আলাদা কোনো সার্ভিস হবে নাকি এটি অ্যাপ্লিকেশনের কোডেই ইমপ্লিমেন্ট বা প্রয়োগ করা উচিত? ইন্টারভিউয়ার: এটি ডিজাইনের সিদ্ধান্ত, যা সম্পূর্ণ আপনার ওপর নির্ভর করছে।

প্রার্থী: যেসব ব্যবহারকারীকে থ্রোটল বা আটকে দেওয়া হবে, তাদের কি আমাদের ইনফর্ম বা জানাতে হবে? ইন্টারভিউয়ার: হ্যাঁ।

রিকোয়ারমেন্টস (Requirements) বা মূল চাহিদাসমূহ

সিস্টেমটির রিকোয়ারমেন্টগুলোর একটি সারসংক্ষেপ নিচে দেওয়া হলো:

• অতিরিক্ত রিকোয়েস্টগুলোকে নিখুঁতভাবে সীমাবদ্ধ (limit) করা।
• লো ল্যাটেন্সি (Low latency): রেট লিমিটারের কারণে যেন এইচটিটিপি রেসপন্স টাইম (HTTP response time) ধীর না হয়ে যায়।
• যতটা সম্ভব কম মেমরি ব্যবহার করা।
• ডিস্ট্রিবিউটেড রেট লিমিটিং (Distributed rate limiting): রেট লিমিটারটি একাধিক সার্ভার বা প্রসেসের মধ্যে শেয়ার করা যেতে পারে।
• এক্সেপশন হ্যান্ডেলিং (Exception handling): যখন ব্যবহারকারীদের রিকোয়েস্ট থ্রোটল বা আটকে দেওয়া হবে, তখন তাদের কাছে পরিষ্কার এক্সেপশন (exceptions) বা বার্তা প্রদর্শন করা।
• হাই ফল্ট টলারেন্স (High fault tolerance): রেট লিমিটারের কোনো সমস্যা হলে (উদাহরণস্বরূপ, যদি ক্যাশ সার্ভার অফলাইনে চলে যায়), এটি যেন সম্পূর্ণ সিস্টেমকে প্রভাবিত না করে।