পাবলিক API-এর জন্য রেট লিমিটিং: ব্যবহারিক কোটা ও লকআউট ফ্লো

রেট লিমিটিং আসলে কোন সমস্যা সমাধান করছে

পাবলিক API-এর জন্য রেট লিমিটিং ব্যবহারকারীদের শাস্তি দেয়ার জন্য নয়। এটা একটা সেফটি ভালভ যা ট্রাফিক অস্বাভাবিক হলে আপনার সার্ভিসকে উপলব্ধ রাখে—চাই সেটা ম্যালিশিয়াস হোক, বা কেবল কোনো ক্লায়েন্ট সেভাবে কাজ না করাই হোক।

"অপব্যবহার" প্রথমে প্রায়ই স্বাভাবিকই লাগে: একটি স্ক্রেপার যা প্রতিটি এন্ডপয়েন্ট ঘুরে ডেটা কপি করছে, ব্রুট-ফোর্স লগইন চেষ্টা, অথেন্টিকেশন রুটে টোকেন স্টাফিং, বা টাইমআউটের পরে একই অনুরোধ খুব দ্রুত পুনরায় পাঠানো হচ্ছে এমন একটি ক্লায়েন্ট। অনেক সময় ওরা আসলেই আক্রমণ করছেনা—একটি মোবাইল অ্যাপ আপডেটে খারাপ ক্যাশিং নিয়ম চলে এলেই হঠাৎ প্রতিটি ডিভাইস প্রতি সেকেন্ডে আপনার API-পােল করে।

কাজটা সরল: আপটাইম রক্ষা করা এবং খরচ নিয়ন্ত্রণ করা, তবে বাস্তব ব্যবহারকারীদের ব্লক না করা। যদি আপনার বেকএন্ডে মিটারিং থাকে (compute, database, email/SMS, AI কল), একটি হট্টগোলকারী অ্যাক্টর দ্রুত বড় বিল বানিয়ে দিতে পারে।

শুধু রেট লিমিটিং যথেষ্ট নয়। পর্যবেক্ষণ এবং স্পষ্ট ত্রুটি রেসপন্স ছাড়া, আপনি পান-ভিত্তিক ব্যর্থতা পাবেন, বিভ্রান্ত কাস্টমার পাবেন, এবং সাপোর্ট টিকিট আসবে যেগুলো শোনায় "আপনার API ডাউন" যখন আসলে সেটা থ্রটেলিং করছে।

পূর্ণরূপে রক্ষা করতে সাধারণত কয়েকটি আলাদা অংশ থাকে:

• রেট লিমিটস: ছোট-উইন্ডো ক্যাপ (প্রতি সেকেন্ড/প্রতি মিনিট) যা স্পাইক থামায়।
• কোটা: লংার-উইন্ডো বরাদ্দ (প্রতি দিন/প্রতি মাস) যা ব্যবহার পূর্বানুমানযোগ্য রাখে।
• লকআউট: স্পষ্ট অপব্যবহার প্যাটার্ন হলে অস্থায়ী ব্লক।
• এক্সসেপশনস: ট্রাস্টেড ইন্টিগ্রেশন, ইন্টারনাল টুল বা ভিআইপি গ্রাহকদের জন্য allowlist।

আপনি যদি AppMaster মতো প্ল্যাটফর্মে API বেকএন্ড বানান, এই নিয়মগুলো তখনো গুরুত্বপূর্ণ। পরিষ্কার, পুনরুজ্জীবিত কোড থাকলেও, একটি খারাপ ক্লায়েন্ট পুরো সার্ভিসকে ডাউন করে দিতে পারে—সেজন্য রক্ষা করার ডিফল্ট দরকার।

মূল শব্দ: রেট লিমিট, কোটা, থ্রটলিং, এবং লকআউট

এই শব্দগুলো একসাথে মিলিয়ে বলা হয়, কিন্তু তারা ভিন্ন সমস্যা সমাধান করে এবং ব্যবহারকারীর জন্য আলাদা অনুভব দেয়।

রেট লিমিট, কোটা, এবং কনকারেন্সি: প্রতিটির মানে কী

একটি রেট লিমিট হচ্ছে গতি-সীমা: একটি ক্লায়েন্ট কতটা দ্রুত অনুরোধ করতে পারে ছোট উইন্ডোতে (প্রতি সেকেন্ড, প্রতি মিনিট)। একটি কোটা হচ্ছে বাজেট: দীর্ঘ সময়ে মোট ব্যবহার (প্রতি দিন, প্রতি মাস)। একটি কনকারেন্সি লিমিট কতগুলি অনুরোধ একসাথে প্রক্রিয়াধীন থাকবে তা সীমাবদ্ধ করে, যা মূল্যবান এন্ডপয়েন্টের জন্য উপকারী এমনকি অনুরোধ রেট স্বাভাবিক দেখালেও।

কোথায় সীমা সংযুক্ত করা হচ্ছে তা গুরুত্বপূর্ণ:

• Per IP: সহজ, কিন্তু শেয়ার্ড নেটওয়ার্কস (অফিস, স্কুল, মোবাইল ক্যারিয়ার) কে শাস্তি দেয়।
• Per user: লগ-ইন অ্যাপগুলোর জন্য ভাল, কিন্তু নির্ভরযোগ্য পরিচয়ের উপর নির্ভর করে।
• Per API key: পাবলিক API-দের জন্য সাধারণ, স্পষ্ট মালিকানা এবং মেসেজ করা সহজ।
• Per endpoint: দরকারী যখন একটি রুট অনেক ভারী অন্যগুলোর তুলনায়।

থ্রটলিং বনাম ব্লকিং, এবং লকআউট কোথায় ফিট করে

সফট থ্রটলিং ক্লায়েন্টকে ধীর করে (ডিলে, কম বার্ষ্ট ক্যাপাসিটি) যাতে তারা পুনরায় ঠিক হতে পারে ভাঙা ছাড়াই। হার্ড ব্লকিং অনুরোধ অবিলম্বে প্রত্যাখ্যান করে, সাধারণত HTTP 429 দিয়ে।

একটি লকআউট সাধারণ 429 থেকেও শক্ত—একটি 429 বলে "শীঘ্রই আবার চেষ্টা করুন।" একটি লকআউট বলে "একটি শর্ত পূরণ না হওয়া পর্যন্ত বন্ধ রাখুন," যেমন কুল-ডাউন পিরিয়ড, ম্যানুয়াল রিভিউ, বা কী রিসেট। লকআউট সংরক্ষণ করুন স্পষ্ট অপব্যবহারের সংকেতের জন্য (ক্রেডেনশিয়াল স্টাফিং, আগ্রাসী স্ক্রেপিং, বারবার অবৈধ অথ), নয় সাধারণ ট্রাফিক স্পাইকগুলোর জন্য।

আপনি যদি AppMaster-এর মতো টুল দিয়ে API গঠন করেন, এগুলো আলাদা কন্ট্রোলে ভাবুন: বার্ষ্ট শোষণের জন্য ছোট-উইন্ডো সীমা, খরচ নিয়ন্ত্রণের জন্য দীর্ঘ-কাঠামোর কোটা, এবং কেবল পুনরাবৃত্ত খারাপ আচরণের জন্য লকআউট।

অনুমান না করে ব্যবহারিক সীমা বেছে নেওয়া

ভাল সীমা শুরু হয় এক লক্ষ্য দিয়ে: ব্যাকএন্ডকে রক্ষা করা যখন বাস্তব ব্যবহারকারীরা তাদের কাজ শেষ করতে পারে। প্রথম দিনে আপনার নিখুঁত সংখ্যা দরকার নেই। একটি নিরাপদ বেসলাইন এবং সেটি সামঞ্জস্য করার উপায় দরকার।

একটি সহজ শুরু পয়েন্ট হলো প্রতি-API-কী সীমা যা আপনার API-এর ধরন অনুযায়ী মিলবে:

• কম ট্রাফিক: প্রতি কী 60–300 অনুরোধ প্রতি মিনিটে
• মাঝারি ট্রাফিক: প্রতি কী 600–1,500 অনুরোধ প্রতি মিনিটে
• উচ্চ ট্রাফিক: প্রতি কী 3,000–10,000 অনুরোধ প্রতি মিনিটে

তারপর এন্ডপয়েন্ট টাইপ অনুযায়ী সীমা ভাগ করুন। রিডস সাধারণত সস্তা এবং বেশি লিমিট নিতে পারে। রাইটস ডেটা পরিবর্তন করে, প্রায়ই অতিরিক্ত লজিক ট্রিগার করে, এবং কঠোর ক্যাপ পাওয়া উচিত। একটি প্রচলিত প্যাটার্ন হলো GET রুটগুলোর জন্য 1,000/মিনিট কিন্তু POST/PUT/DELETE জন্য 100–300/মিনিট।

এছাড়াও ব্যয়বহুল এন্ডপয়েন্টগুলো আলাদা করে চিনুন এবং আলাদা আচরণ দিন। সার্চ, রিপোর্ট জেনারেশন, এক্সপোর্ট, ফাইল আপলোড, এবং যেকোনো কাজ যা একাধিক টেবিলে হিট করে বা ভারী ব্যবসায়িক লজিক চালায় সেগুলো ছোট বাকি বালতিতে রাখা উচিত এমনকি বাকী API উদার হলেও। যদি আপনার বেকএন্ড ভিজ্যুয়াল ওয়ার্কফ্লো ব্যবহার করে (উদাহরণস্বরূপ, Business Process flows), প্রতিটি অতিরিক্ত ধাপই বাস্তব কাজ যা লোডে গুণিত হয়।

বার্ষ্টের জন্য পরিকল্পনা করুন দুইটি উইন্ডো দিয়ে: একটি ছোট উইন্ডো দ্রুত স্পাইক শোষণ করতে, প্লাস একটি বড় উইন্ডো যা স্থায়ী ব্যবহার নিয়ন্ত্রণ করবে। একটি সাধারণ কম্বো হলো 10 সেকেন্ড প্লাস 10 মিনিট। এটি দ্রুত ক্লিক করা ব্যবহারকারীদের সাহায্য করে, স্ক্রেপারদের সীমাহীন গতি না দেয়।

অবশেষে, সিদ্ধান্ত নিন ক্লায়েন্ট সীমা ছাড়িয়ে গেলে কী হবে। বেশিরভাগ পাবলিক API HTTP 429 ফেরত দেয় স্পষ্ট রিট্রাই টাইমসহ। যদি কাজটি দেরি করা নিরাপদ (যেমন একটি এক্সপোর্ট), তাহলে হার্ড-ব্লকিংয়ের পরিবর্তে সেটি কিউয়িং করার কথা বিবেচনা করুন যাতে বাস্তব ব্যবহারকারীরা এখনও ফল পায়।

এমনকি ন্যায্যমূলক মনে হওয়া per-key কোটা ডিজাইন করা

Per-key কোটা সাধারণত সবচেয়ে ন্যায়সঙ্গত কারণ তা গ্রাহকদের ব্যবহারকে মিলায়: একটি অ্যাকাউন্ট, একটি API কী, স্পষ্ট দায়িত্ব। IP-ভিত্তিক সীমা এখনও দরকারী, কিন্তু তারা প্রায়ই নির্দোষ ব্যবহারকারীদের শাস্তি দেয়।

শেয়ার্ড IP-রই বড় কারণ। একটি পুরো অফিস এক পাবলিক IP থেকে বের হতে পারে, এবং মোবাইল ক্যারিয়ার হাজার হাজার ডিভাইসকে ছোট IP পুলের পিছনে রাখতে পারে। যদি আপনি per-IP ক্যাপের উপর নির্ভর করুন, একটি শব্দকারী ব্যবহারকারী সবাইকে ধীর করে দিতে পারে। একটি per-key কোটা সেই ঝামেলা এড়ায়, এবং আপনি একটি ছোট per-IP সীমা ব্যাকস্টপ হিসেবে রাখতে পারেন স্পষ্ট ফ্লড ধরার জন্য।

কোটা ন্যায্য মনে করতে, সেগুলোকে গ্রাহক টিয়ারের সাথে লিঙ্ক করুন কিন্তু নতুন ব্যবহারকারীদের ফাঁদে ফেলবেন না। একটি ফ্রি বা ট্রায়াল কী বাস্তব টেস্টিংয়ের জন্য কাজ করা উচিত, কেবল সেই স্কেলে নয় যা আপনাকে ক্ষতি করে। একটি সাধারণ প্যাটার্ন হলো উদার ব্যার্স্ট, সংযত স্থায়ী হার, এবং প্ল্যান অনুযায়ী দৈনিক কোটা।

একটি per-key নীতি যা পূর্বানুমানযোগ্য থাকে:

• ছোট ব্যার্স্ট অনুমতি দিন (পেজ লোড, ব্যাচ ইম্পোর্ট), তারপর স্থির হার প্রয়োগ করুন।
• প্রতি কী দৈনিক ক্যাপ যোগ করুন স্ক্রাপিং এবং রানঅয়ওয়ে লুপ সীমাবদ্ধ করার জন্য।
• প্ল্যান অনুযায়ী সীমা বাড়ান, কিন্তু একই কাঠামো রাখুন যাতে আচরণ ধারাবাহিক থাকে।
• সদ্য তৈরি কীগুলোর জন্য নিম্নতর ক্যাপ রাখুন যতক্ষণ না তারা ভালো ইতিহাস তৈরি করে।
• স্পষ্ট ফ্লাড ধরার জন্য একটি ছোট per-IP ক্যাপ রাখুন।

কী শেয়ারিং এবং অটোমেটেড সাইনআপ প্রতিহত করতে, আপনাকে ভারী পর্যবেক্ষণের দরকার নেই। সহজ চেক দিয়ে শুরু করুন যেমন অস্বাভাবিক জিও পরিবর্তন, এক ঘণ্টায় এক কীর কাছে অতিরিক্ত ভিন্ন IP, বা একই উৎস থেকে অনেক নতুন কী তৈরি। প্রথমে ফ্ল্যাগ ও ধীর করুন; শুধুমাত্র পুনরাবৃত্ত সংকেত পেলে লক আউট করুন।

অজ্ঞাত ট্র্যাফিক যেখানে কঠোর ক্যাপ বুঝদারির সাথে মানায়। যদি আপনি ট্রায়াল কীর অফার করেন, সেগুলোকে শক্তভাবে রেট-লিমিট করুন এবং সীমা বাড়ানোর আগে একটি মৌলিক যাচাইকরণ ধাপ প্রয়োজন করুন। যদি আপনার API কোনো পাবলিক ফর্ম চালায়, আলাদা অজ্ঞাত এন্ডপয়েন্ট বিবেচনা করুন যার নিজস্ব কোটা যাতে বাকি বেকএন্ড সুরক্ষিত থাকে।

আপনি যদি AppMaster দিয়ে আপনার API বানান, per-key লজিক ধারাবাহিক রাখা সহজ কারণ auth, বিজনেস রুলস, এবং রেসপন্স হ্যান্ডলিং একই জায়গায় থাকে।

ক্লায়েন্ট-বন্ধুত্বপূর্ণ রেসপন্স ও হেডার (তাই ব্যবহারকারীরা পুনরুদ্ধার করতে পারে)

রেট লিমিটিং দীর্ঘমেয়াদে কাজ করে যদি ক্লায়েন্টরা বুঝতে পারে কী হল এবং পরে কী করা উচিত। লক্ষ্য করুন রেসপন্সগুলো কাঁচামাটি হলেও পূর্বানুমানযোগ্য: একই স্ট্যাটাস কোড, একই ফিল্ড, একই অর্থ সব এন্ডপয়েন্টে।

যখন ক্লায়েন্ট সীমা ছাড়িয়ে যায়, HTTP 429 (Too Many Requests) ফিরিয়ে দিন স্পষ্ট বার্তা ও একটি কংক্রিট অপেক্ষার সময় দিয়ে। দ্রুততম জয় হলো Retry-After যোগ করা, কারণ এমনকি সাধারণ ক্লায়েন্টও তখন সঠিকভাবে পজ করতে পারে।

কিছু হেডার সীমাগুলো নিজেই ব্যাখ্যা করার জন্য ভালো। নামগুলো ধারাবাহিক রাখুন এবং সেগুলো সফল রেসপন্সে (তাতে ক্লায়েন্ট নিজে পেস করতে পারে) এবং 429 রেসপন্সেও (তাতে ক্লায়েন্ট পুনরুদ্ধার করতে পারে) উভয় জায়গায় অন্তর্ভুক্ত করুন:

• Retry-After: পুনরায় চেষ্টা করার আগে অপেক্ষা করতে হবে এমন সেকেন্ড
• X-RateLimit-Limit: বর্তমান উইন্ডোতে অনুমোদিত অনুরোধের পরিমাণ
• X-RateLimit-Remaining: বর্তমান উইন্ডোতে বাকি অনুরোধ সংখ্যা
• X-RateLimit-Reset: কখন উইন্ডো রিসেট হবে (epoch সেকেন্ড বা ISO টাইম)
• X-RateLimit-Policy: সংক্ষিপ্ত টেক্সট যেমন "60 requests per 60s"

ত্রুটি বডিটা আপনার সফল রেসপন্সের মতই স্ট্রাকচার্ড রাখুন। একটা সাধারণ প্যাটার্ন হলো একটি error অবজেক্ট যার স্থায়ী code, মানুষ-বন্ধুভাবেই একটি message, এবং পুনরুদ্ধারের ইঙ্গিত।

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after 12 seconds.",
    "retry_after_seconds": 12,
    "limit": 60,
    "remaining": 0,
    "reset_at": "2026-01-25T12:34:56Z"
  }
}

ক্লায়েন্টদের বলুন কিভাবে 429 দেখলে ব্যাক-অফ নিতে। এক্সপোনেনশিয়াল ব্যাকঅফ একটি ভালো ডিফল্ট: 1s অপেক্ষা করুন, তারপর 2s, তারপর 4s, এবং একে একটি ক্যাপ দিন (উদাহরণস্বরূপ, 30–60 সেকেন্ড)। এছাড়াও স্পষ্টভাবে বলুন কখন পুনরায় চেষ্টা বন্ধ করা উচিত।

কোটা কাছাকাছি গেলে আচমকা আচরণ এড়িয়ে চলুন। যখন একটি কী ক্যাপের কাছাকাছি (ধরে নিন 80–90% ব্যবহার), একটি ওয়ার্নিং ফিল্ড বা হেডার অন্তর্ভুক্ত করুন যাতে ক্লায়েন্টরা ব্যর্থ হওয়ার আগেই ধীর হতে পারে। এটা আরো জরুরি যখন একটি স্ক্রিপ্ট একাধিক রুটকে দ্রুত হিট করে এবং বাজেট দ্রুত ঝরিয়ে দিয়ে ফেলা।

ক্ৰমে: সীমা ও কোটা রোলআউট করার সহজ পরিকল্পনা

একটি রোলআউট সবচেয়ে ভাল কাজ করে যখন আপনি সীমাগুলোকে একটি প্রোডাক্ট আচরণ হিসেবে বিবেচনা করেন, না যে কোনো এককালীন ফায়ারওয়াল নিয়ম। লক্ষ্য সব সময় একটাই: ব্যাকএন্ডকে রক্ষা করা যখন সাধারণ গ্রাহকরা চলমান থাকে।

শুরু করুন একটি দ্রুত ইনভেন্টরির সাথে। প্রতিটি এন্ডপয়েন্টের তালিকা করুন, তারপর প্রতিটির খরচ (CPU, ডাটাবেস কাজ, তৃতীয়-পক্ষ কল) এবং ঝুঁকি (লগইন, পাসওয়ার্ড রিসেট, সার্চ, ফাইল আপলোড) চিহ্নিত করুন। এতে আপনি সব জায়গায় একই খাটাল সীমা প্রয়োগ করলে যে সমস্যা হবে তা রোধ হয়।

একটি রোলআউট অর্ডার যা সাধারণত বিস্ময় এড়ায়:

• এন্ডপয়েন্টগুলোকে খরচ ও ঝুঁকির ভিত্তিতে ট্যাগ করুন, এবং সিদ্ধান্ত নিন কোনগুলো কঠোর নিয়ম প্রয়োজন (লগইন, ব্যাচ এক্সপোর্ট)।
• পরিচয়ের কী গুলো প্রাধান্য ক্রমে বেছে নিন: প্রথমে API কী, তারপর user id, এবং IP কেবল ব্যাকআপ হিসেবে।
• শর্ট-উইন্ডো সীমা যোগ করুন (প্রতি 10 সেকেন্ড বা প্রতি মিনিট) স্পাইক ও স্ক্রিপ্ট থামাতে।
• লং-উইন্ডো কোটা যোগ করুন (প্রতি ঘণ্টা বা প্রতি দিন) স্থায়ী ব্যবহার সীমিত করতে।
• অপারেশন টিম ও ট্রাস্টেড সিস্টেমের জন্য allowlist যোগ করুন যাতে ops কাজ ব্লক না হয়ে যায়।

প্রথম রিলিজটা সংরক্ষিত রাখুন। পরে আলগা করা সহজ, ক্ষিপ্ত ব্যবহারকারীদের আনব্লক করা কঠিন।

মনিটর এবং টিউন করুন, তারপর আপনার নীতি ভার্সন করুন। কতগুলি অনুরোধ সীমায় আঘাত করেছে, কোন এন্ডপয়েন্টগুলো সেটা ট্রিগার করেছে, এবং কতগুলি ইউনিক কী প্রভাবিত হলো তা ট্র্যাক করুন। যখন আপনি সংখ্যাগুলো পরিবর্তন করবেন, এটাকে একটি API পরিবর্তন হিসেবে বিবেচনা করুন: ডকুমেন্ট করুন, ধীরে ধীরে রোলআউট করুন, এবং পুরনো ও নতুন নিয়ম আলাদা রাখুন যাতে দ্রুত রোলব্যাক করা যায়।

আপনি যদি AppMaster দিয়ে API তৈরি করেন, এই নিয়মগুলো আপনার এন্ডপয়েন্ট এবং ব্যবসায়িক লজিকের সাথে একসাথে পরিকল্পনা করুন যাতে সীমা প্রতিটি ওয়ার্কফ্লোর বাস্তব খরচের সাথে মিলে।

লকআউট ওয়ার্কফ্লো যাতে অপব্যবহার থামে কিন্তু নাটক না ঘটে

লকআউট হচ্ছে সিটবেল্ট। এগুলো স্পষ্ট অপব্যবহার দ্রুত থামায়, কিন্তু সাধারণ ব্যবহারকারীদের একটি পরিষ্কার পুনরুদ্ধারের পথ দেওয়া উচিত যখন কিছু ভুল হয়ে যায়।

একটি শান্তপাত্র পদ্ধতি হলো প্রগ্রেসিভ শাস্তি। ধরে নিন ক্লায়েন্টটি কনফিগারেশন ভুলে পড়তে পারে, ম্যালিশিয়াস নাও হতে পারে, এবং কেবল একই প্যাটার্ন পুনরাবৃত্ত হলে মাত্র বৃদ্ধি করুন।

একটি সহজ প্রগ্রেসিভ ল্যাডার

কাজ সহজে বোঝার ও বাস্তবায়নযোগ্য করার জন্য ছোট ধাপের সেট ব্যবহার করুন:

• সতর্ক করা: ক্লায়েন্টকে জানান তারা সীমার কাছে পৌঁছাচ্ছে, এবং কখন তা রিসেট হবে।
• ধীর করা: ওই কী-র জন্য ছোট ডিলে বা কড়া প্রতি-সেকেন্ড সীমা যোগ করুন।
• অস্থায়ী লকআউট: কয়েক মিনিটের জন্য ব্লক করুন (ঘন্টার নয়) এবং একটি নির্দিষ্ট আনলক টাইম দিন।
• দীর্ঘতর লকআউট: বহু উইন্ডো জুড়ে পুনরাবৃত্ত স্পাইক হলে।
• ম্যানুয়াল রিভিউ: যেগুলো ইচ্ছাকৃত মনে হয় বা বারবার ফিরে আসে সেগুলোর জন্য।

কী কি লক করা হবে তা গুরুত্বপূর্ণ। Per API key সাধারণত ন্যায্য কারণ এটি কলারকে নিশানা করে, শেয়ার্ড নেটওয়ার্কের সবাইকে নয়। Per account সাহায্য করে যখন ব্যবহারকারীরা কী রোটেট করে। Per IP অজ্ঞাত ট্রাফিকের ক্ষেত্রে সহায়ক, কিন্তু NATs, অফিস, এবং মোবাইল ক্যারিয়ারের জন্য false positive তৈরি করে। যখন অপব্যবহার গম্ভীর, সংকেত গুলো মিলিয়ে ব্যবহার করুন (উদাহরণ: কী লক করুন এবং ঐ IP-এর জন্য অতিরিক্ত চেক লাগান), তবে ব্লাস্ট রেডিয়াস ছোট রাখুন।

লকআউটগুলো সময়-ভিত্তিক রাখুন সহজ নিয়মের সাথে: "blocked until 14:05 UTC" এবং "resets after 30 minutes of good behavior." স্থায়ী ব্যান পরিহার করুন স্বয়ংক্রিয় সিস্টেমের জন্য। একটি বাগ্‌যুক্ত ক্লায়েন্ট দ্রুত লুপ করে সীমা ফেলে দিতে পারে, তাই শাস্তিগুলো সময়ের সাথে কমে যেতে হবে। একটি স্থায়ী নিম্ন-হারের সময়কাল শাস্তি-স্তর কমিয়ে দেয়।

আপনি যদি AppMaster-এ API গঠন করেন, এই ল্যাডারটি স্টোরড কাউন্টার এবং একটি Business Process-এ সহজেই মানচিত্র করা যায়, যা allow, slow, বা block সিদ্ধান্ত নেয় এবং কী-এর আনলক টাইম লিখে দেয়।

পুনরায় অপরাধীদের জন্য একটি ম্যানুয়াল রিভিউ পাথ রাখুন। ব্যবহারকারীর সাথে তর্ক করবেন না। রিকোয়েস্ট আইডি, টাইমস্ট্যাম্প, এবং API কী নাম জিজ্ঞাসা করুন এবং তারপর প্রমাণের ভিত্তিতে সিদ্ধান্ত নিন।

সাধারণ ভুলগুলো যা false positive সৃষ্টি করে

False positives হলো যখন আপনার প্রতিরোধ নর্মাল ব্যবহারকারীদের ব্লক করে। সাধারণত হয় যখন নিয়মগুলো ব্যবহারকারীরা প্রকৃতপক্ষে কিভাবে API ব্যবহার করে তা সহজ করে দেখতে পারে না।

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

শুধু IP-ভিত্তিক লিমিটিং আরেকটি সাধারণ ফাঁদ। অনেক বাস্তব ব্যবহারকারী এক পাবলিক IP শেয়ার করে (অফিস, স্কুল, মোবাইল ক্যারিয়ার)। একটি ভারী ব্যবহারকারী সবাইকে ব্লক করতে পারে, এবং এটা মনে হবে র‍্যান্ডম আউটেজ। প্রথমে per-API-key সীমা প্রাধান্য দিন, তারপর IP-কে একটি সেকেন্ডারি সংকেত হিসেবে ব্যবহার করুন স্পষ্ট অপব্যবহার ধরতে।

ফেইলিওর থেকেও false positives হয়। যদি আপনার limiter স্টোর ডাউন থাকে, "fail closed" পুরো API ডাউন করে দিতে পারে। "Fail open" স্পাইককে আমন্ত্রণ জানায় যা আপনার ব্যাকএন্ড নামিয়ে দিতে পারে। একটি পরিষ্কারFallback বেছে নিন: এজে একটি ছোট জরুরি ক্যাপ রাখুন, এবং অগুরুত্বপূর্ণ এন্ডপয়েন্টে সুন্দরভাবে degrade করুন।

ক্লায়েন্ট হ্যান্ডলিং বেশি গুরুত্বপূর্ণ যা অধিকাংশ টিম আশা করে না। যদি আপনি একটি সাধারণ 429 ফেরত দেন স্পষ্ট বার্তা না দিয়ে, ব্যবহারকারীরা আরও কড়োরভাবে আবার চেষ্টা করবে এবং আরও ব্লক ট্রিগার হবে। সর্বদা Retry-After পাঠান, এবং ত্রুটি টেক্সট নির্দিষ্ট রাখুন ("Too many requests for this key. Try again in 30 seconds.").

সবচেয়ে এড়নীয় সমস্যা হলো গোপনীয়তা। লুকানো সীমা মনে হবে বাগ যখন কাস্টমাররা প্রোডাকশনে প্রথমবার লোড করে। একটি সহজ নীতি শেয়ার করুন এবং প্রচলিত রাখুন।

False positives এড়ানোর দ্রুত চেকলিস্ট:

• ব্যয়বান বনাম সস্তা এন্ডপয়েন্টের জন্য আলাদা সীমা
• মূল সীমা per API key দিয়ে, শুধুমাত্র IP নয়
• limiter উপলব্ধ না থাকলে সংজ্ঞায়িত আচরণ
• স্পষ্ট 429 রেসপন্স Retry-After সহ
• সীমাগুলো ডকুমেন্টেড এবং কার্যকর হওয়ার আগে যোগাযোগ করা

আপনি যদি AppMaster দিয়ে API বানান, এর মানে প্রায়শই প্রতিটি এন্ডপয়েন্টে বিভিন্ন ক্যাপ সেট করা এবং ধারাবাহিক ত্রুটি পে লোড ফেরত দেওয়া যাতে ক্লায়েন্টরা অনুমান না করে ব্যাক-অফ নিতে পারে।

মনিটরিং ও এলার্টিং যা বাস্তবে সাহায্য করে

রেট লিমিটিং কেবল তখন কাজ করে যখন আপনি বাস্তবে যা হচ্ছে তা দেখতে পারেন। লক্ষ্য প্রত্যেক স্পাইক ধরার নয়—লক্ষ্য হলো সেই প্যাটার্নগুলো শনাক্ত করা যা আউটেজ বা রাগী ব্যবহারকারীতে পরিণত হতে পারে।

একটি ছোট সেট সিগন্যাল দিয়ে শুরু করুন যা ভলিউম এবং উদ্দেশ্য উভয় কভার করে:

• প্রতি মিনিট অনুরোধ (সামগ্রিক এবং per API key)
• 429 রেট (থ্রটেলেড অনুরোধ) এবং 5xx রেট (বেকএন্ডে সমস্যা)
• পুনরাবৃত্ত 401/403 স্পাইক (খারাপ কী, ক্রেডেনশিয়াল স্টাফিং, কনফিগার্ড ক্লায়েন্ট)
• ভলিউম ও খরচ দ্বারা শীর্ষ এন্ডপয়েন্ট (স্লো কোয়েরি, ভারি এক্সপোর্ট)
• শীর্ষ 10-এ নতুন বা অপ্রত্যাশিত এন্ডপয়েন্ট

"খারাপ ট্র্যাফিক" কে "আমরা কিছু শিপ করেছি" থেকে আলাদা করতে ড্যাশবোর্ডে প্রসঙ্গ যোগ করুন: ডিপ্লয় টাইম, ফিচার ফ্ল্যাগ পরিবর্তন, মার্কেটিং সেন্ড। যদি ট্রাফিক ডিপ্লয় পরপর বাড়ে এবং 429/5xx মিশ্রণ ভালো থাকে, এটা সাধারণত গ্রোথ, অপব্যবহার নয়। যদি ঝাপ concentrated হয় একটি কী, একটি IP রেঞ্জ, বা একটি ব্যয়বহুল এন্ডপয়েন্টে, সেটা সন্দেহজনক বলুন।

এলার্টগুলো মৃতপ্রায় হওয়া উচিত। থ্রেশহোল্ড ও কুলডাউন ব্যবহার করুন যাতে আপনি একই ঘটনায় প্রতি মিনিটে পেজ না পান:

• 429 রেট X%-এর উপরে 10 মিনিট ধরে, প্রতি ঘন্টায় একবার নোটিফাই
• 5xx Y%-এর উপরে 5 মিনিট ধরে, তাত্ক্ষণিক পেজ
• একটি কী 15 মিনিট ধরে কোটা Z%-এর বেশি ছাড়িয়ে যায়, তদন্ত খুলুন
• 401/403 স্পাইক N/min-এর উপরে, সম্ভাব্য অপব্যবহারের জন্য ফ্ল্যাগ

যখন এলার্ট বাজে, একটি সংক্ষিপ্ত ইনসিডেন্ট নোট রাখুন: কী বদলেছে, আপনি কি দেখলেন (শীর্ষ কী/এন্ডপয়েন্ট), এবং আপনি কী সমন্বয় করেছেন (সীমা, ক্যাশ, অস্থায়ী ব্লক)। সময়ের সাথে এই নোটগুলোই আপনার আসল প্লেবুক হয়ে ওঠে।

উদাহরণ: আপনি একটি নতুন সার্চ এন্ডপয়েন্ট লঞ্চ করেছেন এবং ট্রাফিক দ্বিগুণ হয়েছে। যদি বেশিরভাগ কল সেই এন্ডপয়েন্টে বহু কী-তে হয়, per-key কোটা সামান্য বাড়ান এবং এন্ডপয়েন্টটি অপটিমাইজ করুন। যদি একটি কী একটানা এক্সপোর্ট হিট করে ল্যাটেন্সি বাড়ায়, ঐ এন্ডপয়েন্ট আলাদাভাবে ক্যাপ করুন এবং মালিককে যোগাযোগ করুন।

দ্রুত চেকলিস্ট: লঞ্চের আগে ও পরে স্যানিটি চেক

কাজ করছে যখন একটি ভাল সেটআপ বিরক্তিকর হয়। এই চেকলিস্টগুলো সেই সমস্যাগুলো ধরবে যা সাধারণত false positives বা স্পষ্ট গ্যাপ তৈরি করে।

নতুন এন্ডপয়েন্ট রিলিজ করার আগে

স্টেজিংয়ে এগুলো পরীক্ষা করুন এবং লঞ্চের পর দ্রুত আবার পরীক্ষা করুন:

• Identity: নিশ্চিত করুন limiter সঠিক জিনিসকে কী করে (প্রথমে API key, তারপর user বা IP ব্যাকআপ), এবং রোটেট করা কীগুলো পুরনো penalty উত্তরাধিকার না করে।
• Limits: একটি ডিফল্ট per-key কোটা সেট করুন, তারপর এন্ডপয়েন্ট খরচ অনুযায়ী সামঞ্জস্য করুন (সস্তা রিড বনাম ব্যয়বহুল রাইট) এবং প্রত্যাশিত ব্যার্স্ট বিবেচনা করুন।
• Responses: স্পষ্ট স্ট্যাটাস এবং পুনরুদ্ধার তথ্য ফেরত দিন (retry timing, remaining budget, স্থায়ী ত্রুটি কোড)।
• Logs: রেকর্ড করুন কার ওপর সীমা লাগানো হয়েছে (কী/ব্যবহারকারী/IP), কোন রুট, কোন নিয়ম চালু হয়েছে, এবং সাপোর্টের জন্য একটি রিকোয়েস্ট ID।
• Bypass: আপনার মনিটর এবং ট্রাস্টেড ইন্টিগ্রেশনগুলোর জন্য জরুরি allowlist রাখুন।

আপনি যদি AppMaster-এ বিল্ড করেন, প্রতিটি নতুন API এন্ডপয়েন্টকে একটি কস্ট-টিয়ার সিদ্ধান্ত হিসেবে বিবেচনা করুন: একটি সহজ লুকআপ উদার হতে পারে, যেখানে যে কোনো কিছু ভারী ব্যবসায়িক লজিক চালায় সেটা শুরুতে কঠোর রাখা উচিত।

যখন একটি ইনসিডেন্ট হয় (অপব্যবহার বা হঠাৎ ট্রাফিক)

ব্যাকএন্ডকে রক্ষা করুন এবং বাস্তব ব্যবহারকারীরা পুনরুদ্ধার করতে পারে:

• ঝুঁকি কম এমন রুটগুলো অস্থায়ীভাবে ক্যাপ বাড়ান (প্রায়শই রিডস) এবং ত্রুটি রেট পর্যবেক্ষণ করুন।
• তদন্ত করার সময় পরিচিত ভাল গ্রাহকদের জন্য সংক্ষিপ্ত allowlist যোগ করুন।
• গ্লোবাল লিমিট কমানোর বদলে নির্দিষ্ট ঝুঁকিপূর্ণ রুট কঠোর করুন।
• শেয়ার্ড নেটওয়ার্ক ব্লক এড়াতে আরও শক্তিশালী পরিচয় (API কীগুলো প্রয়োজন) চালু করুন।
• স্যাম্পল ক্যাপচার করুন: শীর্ষ কী, শীর্ষ IP, ইউজার এজেন্টস, এবং সঠিক পে লোড প্যাটার্ন।

কাস্টমারের জন্য সীমা বাড়ানোর আগে, তাদের সাধারণ রিকোয়েস্ট প্যাটার্ন, এন্ডপয়েন্ট মিক্স, এবং তারা ব্যাচ বা ব্যাকঅফ যোগ করতে পারে কিনা যাচাই করুন। এছাড়াও নিশ্চিত করুন তারা একাধিক অ্যাপে একটি কী শেয়ার করছে না।

মাসিকভাবে পর্যালোচনা করুন: শীর্ষ লিমিট হওয়া এন্ডপয়েন্ট, ট্রাফিকের কত শতাংশ সীমা ছুঁয়েছে, নতুন উচ্চ-খরচ রুট, এবং আপনার কোটা এখনও বাস্তব ব্যবহারের সাথে মেলে কিনা।

উদাহরণ দৃশ্য: ব্যবহারকারীদের ভাঙ না করে একটি বাস্তব পাবলিক API রক্ষা করা

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

এক বিকেলে, একটি পার্টনার একটি বাগ্‌যুক্ত ইন্টিগ্রেশন পাঠায়। এটি ব্যর্থ অনুরোধগুলো তীব্রভাবে পুনরায় চেষ্টা করা শুরু করে, একই API কী থেকে প্রতি সেকেন্ডে 200 অনুরোধ পাঠায়। কোনো রক্ষা ছাড়া, ঐ একটি কী সবাইকে আউট কনকিউরেন্স করে দেয়।

Per-key সীমা বিস্তারের ব্লাস্ট রেডিয়াস ধরে রাখে। বাগযুক্ত কী তার প্রতি-মিনিট ক্যাপে পৌঁছে যায়, 429 রেসপন্স পায়, এবং বাকিদের কাজ চালিয়ে যেতে দেয়। আপনি সম্ভবত ব্যয়বহুল এন্ডপয়েন্টগুলোর জন্য আলাদা, নিম্নতর সীমাও রাখেন যাতে এমনকি "অনুমোদিত" ট্রাফিকও ডাটাবেস ওভারলোড না করে।

একই সময়ে, একটি ব্রুট-ফোর্স লগইন চেষ্টা অথ এন্ডপয়েন্টকে কুণ্ঠিত করছে। পুরো IP রেঞ্জ ব্লক করার বদলে (যা NAT-এ থাকা বাস্তব ব্যবহারকারীদের আঘাত করে), আপনি সেটি ধীর করে তারপর আচরণ অনুযায়ী লকআউট করেন: একাউন্ট প্রতি প্রচুর ব্যর্থ চেষ্টা প্লাস সংক্ষিপ্ত উইন্ডোতে per IP। আক্রমণকারী প্রগ্রেসিভভাবে দীর্ঘ অপেক্ষার সময় পায়, তারপর একটি অস্থায়ী লক।

একজন বাস্তব গ্রাহক যিনি কয়েকবার ভুল পাসওয়ার্ড টাইপ করেছেন তিনি পুনরুদ্ধার করতে পারেন কারণ আপনার রেসপন্সগুলো স্পষ্ট ও পূর্বানুমানযোগ্য:

• 429 এবং Retry-After যাতে ক্লায়েন্ট জানে কখন পুনরায় চেষ্টা করতে হবে
• ছোট লকআউট উইন্ডো (উদাহরণস্বরূপ, 10–15 মিনিট), স্থায়ী ব্যান নয়
• ধারাবাহিক ত্রুটি মেসেজ যা এটা প্রসারিত করে না যে কোন অ্যাকাউন্ট আছে কিনা

ফিক্স নিশ্চিত করতে, আপনি কিছু মেট্রিক মনিটর করবেন:

• API কী এবং এন্ডপয়েন্ট অনুযায়ী 429 রেট
• অথ ব্যর্থ রেট এবং লকআউট কاؤن্ট
• ইনসিডেন্টের সময় P95 লেটেন্সি এবং ডাটাবেস CPU
• প্রভাবিত ইউনিক কীগুলোর সংখ্যা (কম হওয়া উচিত)

এটাই সেই রক্ষাকারী রেট লিমিটিং দেখায় যা আপনার বেকএন্ডকে আচ্ছাদন করে কিন্তু বাস্তব ব্যবহারকারীদের শাস্তি দেয় না।

পরবর্তী ধাপ: একটি ছোট নীতি স্থাপন করুন এবং পুনরাবৃত্তি করুন

প্রথম দিনে নিখুঁত মডেল লাগবে না। একটি ছোট, স্পষ্ট নীতি দিয়ে শুরু করুন এবং বাস্তব ব্যবহারকারীদের আচরণ শিখতে শিখতে উন্নত করুন।

একটি শক্ত নোদিন ভার্সন সাধারণত তিনটি অংশে থাকে:

• একটি per-key বেসলাইন (প্রতি মিনিট অনুরোধ) যা বেশিরভাগ এন্ডপয়েন্ট কভার করে
• ব্যয়বহুল এন্ডপয়েন্টগুলোর জন্য কঠোর ক্যাপ (সার্চ, এক্সপোর্ট, ফাইল আপলোড, জটিল রিপোর্ট)
• ছোট বার্তা সহ স্পষ্ট 429 রেসপন্স যা ক্লায়েন্টকে বলে পরবর্তী করণীয়

কেবল সেই জায়গাগুলোতে লকআউট যোগ করুন যেখানে অপব্যবহার ঝুঁকি বেশি এবং ইরাদা সহজে বোঝা যায়। সাইনআপ, লগইন, পাসওয়ার্ড রিসেট, এবং টোকেন ক্রিয়েশন প্রায়শই উপযুক্ত। শুরুতে লকআউট ছোট রাখুন (মিনিট, দিন নয়), এবং প্রগ্রেসিভ ফ্রিকশনের পছন্দ দিন: ধীরে ধরা, তারপর অস্থায়ী ব্লক, তারপর শক্তিশালী চেক প্রয়োজন।

নীতিটা সরল ভাষায় লিখে রাখুন যাতে সাপোর্ট ইঞ্জিনিয়ারিং ছাড়াই ব্যাখ্যা করতে পারে। এতে কি সীমাবদ্ধ (per API key, per IP, per account), রিসেট উইন্ডো, এবং কিভাবে কাস্টমার পুনরুদ্ধার করতে পারে তা অন্তর্ভুক্ত করুন।

যদি আপনি নতুন বেকএন্ড তৈরি করার সময় এটি বাস্তবায়ন করেন, AppMaster একটি বাস্তবানুগ মিল হতে পারে: আপনি ভিজ্যুয়ালি API তৈরি করতে পারেন, কাউন্টার ও লকআউট সিদ্ধান্তসহ বিজনেস ওয়ার্কফ্লো সংজ্ঞায়িত করতে পারেন, তারপর ক্লাউডে ডেপ্লয় করুন অথবা যখন পূর্ণ নিয়ন্ত্রণ দরকার তখন জেনারেট করা সোর্স কোড এক্সপোর্ট করুন।