Cascading Failure: saturation, retry storm ও blast radius
Saturation, Retry Storms, and Blast Radius
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Saturation এবং retry storm-এর feedback বোঝা
- Timeout, retry budget ও admission control মেলানো
- Recovery-তে backlog pressure সামলানো
সমস্যা দিয়ে শুরু
Payment API ধীর। Laravel request timeout হওয়ার আগেই user আবার click করেন, application-ও তিনবার retry করে। PHP workers অপেক্ষায় ভরে যায়, health check fail করে, balancer বাকি server-এ load বাড়ায়। মূল provider slowness পুরো দোকান বন্ধ করে দিল। Cascade-এ একটি component-এর failure অন্য component-এর overload সৃষ্টি করে, এবং retry positive feedback loop তৈরি করে।
সহজ করে বুঝি
Saturation মানে constrained resource প্রায় পূর্ণ: connection, worker slot, queue বা CPU। Timeout waiting bounded করে; retry অতিরিক্ত কাজ সৃষ্টি করে। Retry budget, exponential backoff, jitter এবং maximum attempts সেই amplification নিয়ন্ত্রণ করে। Admission control নতুন কাজ সীমিত করে, load shedding কম গুরুত্বপূর্ণ কাজ বাদ দেয়। Circuit breaker repeated failing call সাময়িক বন্ধ করতে পারে; correctness ও user messaging আলাদা design।
পরিচিত একটি উপমা
বৃষ্টি দেখে সবাই একই সরু দরজায় ফিরে এলে ভিড় বাড়ে। প্রত্যেকে বারবার সামনে ধাক্কা দিলে কেউই বের হতে পারে না। Line সীমিত রাখা, বিকল্প route এবং কিছু কাজ পরে করার ব্যবস্থা পুরো ব্যবস্থা আটকে যাওয়া ঠেকায়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD S[Slow dependency] --> W[Workers wait] W --> T[Timeouts] T --> R[Unbounded retries] R --> L[More dependency load] L --> S B[Retry budget and admission limit] -.-> R D[Load shedding] -.-> W
Slow dependency worker ধরে রাখে। Timeout-এর পরে uncontrolled retry নতুন চাপ তৈরি করে এবং মূল dependency আরও ধীর হয়। Dashed controls loop দুর্বল করে: retries bounded হয়, low-priority work reject বা defer হয়। Recovery-তে সব queued work একসঙ্গে ছাড়লে আবার overload হয়, তাই gradual draining এবং dependency capacity budget দরকার।
PHP ও Laravel-এ প্রয়োগ
Laravel HTTP client fragment একটি read-only status lookup-এর জন্য। Timeout illustrative bounded values, universal setting নয়। এখানে intentional automatic retry নেই; write/payment capture retry-তে idempotency contract দরকার। Failure safe response বা cached stale status দেওয়ার সিদ্ধান্ত controller/service-এ explicit রাখুন।
use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Log;
try {
$response = Http::connectTimeout(1)->timeout(3)
->get(config('services.payments.status_url'));
$response->throw();
} catch (\Throwable $exception) {
Log::warning('payment_status_unavailable');
throw $exception;
}সুবিধা, সীমাবদ্ধতা ও trade-off
Aggressive retry transient failure ঢাকতে পারে, কিন্তু overload বাড়ায়। Short timeout resource ছাড়ে, কিন্তু legitimate slow operation falsely fail করে। Load shedding কিছু user কাজ reject করে যাতে critical user journey বেঁচে থাকে। Queue buffering burst মসৃণ করে কিন্তু unbounded backlog future outage বানায়। Capacity ও business priority দিয়ে policy বাছুন।
সাধারণ ভুল
- সব layer-এ আলাদা তিন retry দিয়ে total amplification না হিসাব করা।
- Timeout-এর পরে payment হয়নি নিশ্চিত ধরা।
- Recovery-তে সব worker একসঙ্গে full speed চালানো।
আরও একটু গভীরে
Client, gateway, Laravel এবং SDK প্রত্যেকে retry করলে attempts multiplicative হতে পারে। End-to-end deadline এবং single retry owner নির্বাচন সহায়ক। Idempotency duplicate business effect কমায়, resource amplification নিজে বন্ধ করে না। Bulkhead দিয়ে noncritical integration-এর connection/worker budget আলাদা করুন। Health routing flapping capacity কমাচ্ছে কি না দেখুন। Observability collector নিজেও overload-এ drop করলে evidence gap নথিবদ্ধ করুন।
মনে রাখুন
Failure cascade resource অপেক্ষা ও অতিরিক্ত retry-তে বাড়ে; bounded work, isolation ও gradual recovery loop ভাঙে।
নিজে চেষ্টা করুন
তিন layer-এ তিন attempt হলে worst-case downstream attempts হিসাব করুন। Checkout এবং analytics-এর আলাদা resource budget লিখুন। Provider ফিরে এলে queue backlog কী rate-এ drain করবেন তার পরিকল্পনা দিন।
নিজের বোঝা যাচাই করুন
1. Retry সবসময় ভালো?
না। Transient error সামলালেও overloaded dependency-তে কাজ বাড়ায়। Budget, backoff ও clear ownership দরকার।
2. Timeout মানে কাজ হয়নি?
না। Caller response না পেলেও downstream কাজ commit করতে পারে। Unknown outcome reconcile করুন।
3. Queue কি অসীম buffer?
না। Backlog storage এবং completion delay বাড়ায়। Admission ও expiry policy প্রয়োজন।
4. Idempotency retry load কমায়?
Business duplicate effect কমাতে পারে, কিন্তু repeated network ও database work পুরোটা বন্ধ করে না।
5. Recovery gradual কেন?
Backlog একসঙ্গে ছাড়লে dependency পুনরায় saturate হতে পারে। Observed capacity অনুযায়ী drain করুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।