পাঠ্যক্রম খুলুন
অগ্রসর পর্যায়

Distributed Rate Limiter-এর নকশা

Distributed Rate Limiter

এই পাঠের কুইজ ↓৬ মিনিট পড়াPHP 8.3+ · Laravel 12
এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

  • Distributed atomic check-and-update design
  • Algorithm, identity ও failure policy নির্বাচন
  • Redis hot key ও fairness সামলানো

সমস্যা দিয়ে শুরু

API key প্রতি মিনিটে ১০০ request অনুমোদিত। চার Laravel replica নিজস্ব memory counter রাখায় client ৪০০ request করেন। Shared Redis নিলেও check ও increment আলাদা হলে concurrent request limit পেরোতে পারে। Requirements: per-key quota, burst policy, response headers এবং operator visibility। Billing accuracy, security protection ও fair usage আলাদা goal; একটি approximate limiter সব goal পূরণ নাও করতে পারে।

সহজ করে বুঝি

Fixed window সহজ কিন্তু boundary burst অনুমোদন করে। Sliding log accurate recent window দেয়, memory খরচ বেশি। Token bucket steady refill-এর পাশাপাশি bounded burst দেয়। Distributed limiter-এ identity, clock source, atomic mutation ও key expiry গুরুত্বপূর্ণ। Redis Lua script single server execution-এর মধ্যে read/decision/update atomic করতে পারে। Cluster-এ multi-key operation একই hash slot constraint মেনে চলতে হতে পারে।

পরিচিত একটি উপমা

এক counter-এর clerk token গুনে একসঙ্গে entry register update করেন। চার clerk আলাদা খাতা রাখলে total quota মেলে না। গুনে পরে আলাদা সময়ে লিখলে মাঝখানে অন্য clerk একই অবশিষ্ট token ব্যবহার করে ফেলতে পারেন।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

বণ্টিত limiter-এর মূল challenge shared atomic decision; algorithm, identity ও Redis failure policy business risk অনুযায়ী বাছুন।
Diagram-এর text flow দেখুন
flowchart LR
 R[API request] --> I[Resolve trusted identity]
 I --> A[Atomic limiter operation]
 A --> S[(Shared Redis state)]
 A -->|Allowed| P[Laravel handler]
 A -->|Denied| X[429 and retry guidance]
 F[Redis failure policy] -.-> A

Trusted API key/user identity server resolve করে; raw forwarded IP অন্ধভাবে নয়। Atomic operation window count বা token balance বদলায়। Allowed request application-এ যায়, denied response 429 ও appropriate retry guidance দেয়। Redis failure হলে fail-open availability বাঁচায় কিন্তু abuse risk বাড়ায়; fail-closed critical customerও আটকাতে পারে। Endpoint risk অনুযায়ী policy নির্ধারণ করুন।

PHP ও Laravel-এ প্রয়োগ

Assumption: ৫০ হাজার active key এবং minute window-এ একটি counter/key হলে state bounded; actual Redis overhead payload bytes-এর চেয়ে বেশি। API middleware applies quota; metrics bounded outcome labels নেবে। নিচের Laravel RateLimiter definition supported framework primitive ব্যবহার করে; compatible Redis-backed cache/limiter configured, auth middleware আগে identity দেয়। Internals-এর semantics এবং concurrency আপনার selected driver/version-এ test করুন।

php
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;
RateLimiter::for('customer-api', function ($request) {
    $key = $request->user()?->id ?? $request->ip();
    return Limit::perMinute(100)->by('customer:'.$key);
});

সুবিধা, সীমাবদ্ধতা ও trade-off

Central counter সহজ global policy দেয়, network dependency ও hot-key contention আনে। Local token batching Redis call কমায় কিন্তু limit overshoot হতে পারে। Fixed window inexpensive, fairness boundary কম smooth। Global exact quota multi-region network latency ও partition trade-off আনে। Security-sensitive login এবং read-only public catalog-এর failure policy একই হওয়ার প্রয়োজন নেই।

সাধারণ ভুল

  • প্রতিটি replica-র local counter-কে global quota বলা।
  • Redis GET তারপর SET আলাদা করে race উপেক্ষা করা।
  • Untrusted X-Forwarded-For দিয়ে attacker identity বদলাতে দেওয়া।

আরও একটু গভীরে

Key expiry script-এর atomic path-এ রাখুন, নইলে abandoned counter জমতে পারে। Lua script heavy হলে Redis-এর অন্য কাজ delay হয়; bounded constant-time logic ভালো। Multi-dimensional per-user/per-tenant limits evaluate order ও fairness নির্ধারণ করে। Retry-After message request automation নিয়ন্ত্রণে সাহায্য করে কিন্তু malicious client মানবে না। Admission control এবং downstream concurrency limit rate quota-এর পরিপূরক।

মনে রাখুন

বণ্টিত limiter-এর মূল challenge shared atomic decision; algorithm, identity ও Redis failure policy business risk অনুযায়ী বাছুন।

নিজে চেষ্টা করুন

দশ concurrent process দিয়ে একই quota exhaust করার test design করুন। Window boundary burst, Redis outage এবং spoofed forwarded-IP scenario লিখুন। Exact global quota ও local batching-এর overshoot trade-off ব্যাখ্যা করুন।

নিজের বোঝা যাচাই করুন

1. Shared Redis হলেই atomic?

না। Client-side পৃথক read ও update-এর মাঝে race হয়। Supported atomic primitive বা script দরকার।

2. Fixed window-এর সীমা?

Window boundary-র আগে ও পরে burst হতে পারে। Sliding বা token-based policy ভিন্ন trade-off দেয়।

3. IP identity যথেষ্ট?

NAT অনেক user ভাগ করে, proxy header spoof হতে পারে। Trusted proxy config ও authenticated key বেশি উপযুক্ত হতে পারে।

4. Redis down হলে?

Fail-open বা fail-closed deliberate decision। Availability এবং abuse/cost risk অনুযায়ী endpoint policy দিন।

5. Rate limit কি concurrency limit?

না। Request arrival rate এবং simultaneously active work ভিন্ন। Slow request-এ concurrency budgetও দরকার।

আরও পড়ুন

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।