Rate Limiting: request-এর সীমা ও ন্যায্য ব্যবহার
Rate Limiting and Throttling
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Rate limit, throttle ও quota
- Fixed/sliding window ও token bucket
- Laravel route limiter-এর identity scope
সমস্যা দিয়ে শুরু
এক user search endpoint-এ প্রতি সেকেন্ডে হাজার request পাঠিয়ে database ব্যস্ত করছেন। অন্য user-দের ছোট request-ও ধীর। Rate limiting নির্দিষ্ট identity/time policy অনুযায়ী গ্রহণযোগ্য কাজ সীমিত করে। এটি resource capacity বাড়ায় না; abusive বা অতিরিক্ত demand-এর মধ্যে fairness ও protection দেয়।
সহজ করে বুঝি
Fixed window-এ নির্দিষ্ট সময়ের counter থাকে; window boundary-তে burst বেশি হতে পারে। Sliding log exact recent timestamps রাখে কিন্তু memory cost বাড়ে; approximate sliding counter কম state-এ estimate দেয়। Token bucket সময়ের সঙ্গে token ভরে এবং bounded burst অনুমতি দেয়। Leaky bucket steady drain-এর model। Quota দীর্ঘমেয়াদি entitlement, throttle runtime enforcement বোঝাতে ব্যবহৃত হয়। Algorithm-এর নামের সঙ্গে units, scope ও reject behavior contract-এ লিখুন।
পরিচিত একটি উপমা
লাইব্রেরি সদস্য দিনে পাঁচটি বই নিতে পারেন—quota। Counter প্রতি মিনিটে কত request নেবে—runtime throttle। জমিয়ে রাখা token ব্যবহার করে একসঙ্গে কয়েকটি বই নেওয়া burst allowance-এর মতো। তবে library capacity আর membership entitlement আলাদা constraint।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD
R[Authenticated search request] --> K[Build user scoped key]
K --> C{Within minute budget}
C -->|Yes| Q[Bounded search query]
C -->|No| E[429 with retry guidance]
Q --> O[Response]Identity key user ID-ভিত্তিক। Anonymous client-এ trusted resolved IP fallback হতে পারে, কিন্তু shared NAT-এ বহু user একই IP share করেন। Reject response-এর পরে client backoff করবে। Limiter store unavailable হলে fail-open/fail-closed policy আগেই ঠিক করতে হয়; storefront read ও costly paid operation-এর policy আলাদা হতে পারে।
PHP ও Laravel-এ প্রয়োগ
AppServiceProvider::boot method-এর fragment। Route-এ throttle:search middleware এবং authenticated হলে আপনার configured auth middleware দিন। সব app replica একই configured limiter cache store ব্যবহার করবে। এটি ৬০/minute illustrative policy; production budget workload থেকে ঠিক করুন।
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;
public function boot(): void
{
RateLimiter::for('search', function (Request $request) {
$identity = $request->user()?->id ?? $request->ip();
return Limit::perMinute(60)->by('search:'.$identity);
});
}সুবিধা, সীমাবদ্ধতা ও trade-off
Limits fairness ও downstream cost protection দেয়। খুব strict IP limit corporate network-এর নিরীহ user-দের আটকে দিতে পারে। User limit account farming আটকায় না; global concurrency cap বা endpoint cost limit-ও লাগতে পারে। Window boundary burst system সহ্য করতে না পারলে smoother algorithm বেছে নিন। Laravel helper ব্যবহার করলেই arbitrary algorithm-এর guarantee দাবি করবেন না; configured middleware/store behavior পরীক্ষা করুন।
সাধারণ ভুল
- Untrusted X-Forwarded-For থেকে identity নেওয়া।
- প্রতিটি replica-তে independent local counter রেখে global limit বলা।
- Rate limiting-কে authentication বা DDoS protection-এর পূর্ণ বিকল্প ভাবা।
আরও একটু গভীরে
Limiter key-এ tenant, endpoint ও plan প্রাসঙ্গিক হতে পারে। তবে high-cardinality arbitrary input memory বাড়ায়। Success/failure response-এর জন্য আলাদা budget দিলে brute-force defense ও normal traffic policy ভালো মেলে। Repeated 429-এ exponential backoff/jitter client-কে cooperative করে। Limit headers resource balance বুঝতে সাহায্য করতে পারে; exact header contract documentation-এ দিন এবং mutable internal counters leak না করতে দেখুন।
মনে রাখুন
কত কাজ, কার জন্য, কত সময়ে এবং অতিক্রম করলে কী হবে—চারটি প্রশ্ন লিখুন। Shared state ও trusted identity global policy-এর ভিত্তি। Capacity protection-এ concurrency ও cost-ও দেখুন।
নিজে চেষ্টা করুন
এক user, দুই user এবং একটি shared IP দিয়ে staging request চালান। Minute boundary-র আগে-পরে burst test করুন। 429 body/headers ও limiter store outage-এর expected behavior লিখে business owner-এর objective-এর সঙ্গে মেলান।
নিজের বোঝা যাচাই করুন
1. Quota আর limit একই?
অনেক ব্যবহারে overlap করে, তবে long-term entitlement ও short-term protection আলাদা করে design করলে policy পরিষ্কার হয়।
2. Fixed window-এ burst কেন?
এক window-এর শেষে full budget এবং পরেরটির শুরুতে আবার full budget ব্যবহার হতে পারে। Short interval-এ মোট কাজ expected average-এর চেয়ে বেশি।
3. IP কি user identity?
শুধু network signal। NAT, proxy ও address changes-এ একাধিক user share বা একজন বহু IP পেতে পারেন।
4. Local cache global limit?
প্রতিটি replica আলাদা counter রাখলে aggregate allowance বেড়ে যায়। Shared atomic enforcement বা explicit per-node budget দরকার।
5. 429 এলে client কী করবে?
Documented retry guidance মানবে, backoff করবে এবং repeated blind retry এড়াবে। Non-idempotent operation-এর retry correctness আলাদা বিষয়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।