পাঠ্যক্রম খুলুন

অগ্রসর পর্যায়

Circuit Breaker ও Bulkhead: failure ছড়ানো কমানো

Circuit Breakers, Bulkheads, and Graceful Degradation

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনTimeout ও Retry: deadline, backoff ও jitter ↗

এই পাঠের সূচিপত্র

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

Circuit breaker-এর তিন state বুঝুন
Bulkhead দিয়ে resource আলাদা করুন
Graceful degradation-এর সীমা দিন

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

Recommendation API down, কিন্তু Laravel checkout worker একই connection pool ধরে অপেক্ষা করছে। Noncritical recommendation failure পুরো দোকান বন্ধ করছে। Timeout আছে তবুও নতুন request একই ব্যর্থ dependency-তে জমছে।

সহজ করে বুঝি

Circuit breaker repeated failure-এর পরে open হয়ে কিছু সময় call বন্ধ রাখে। Closed অবস্থায় normal traffic, half-open অবস্থায় সীমিত probe recovery পরীক্ষা করে। Bulkhead resource pool আলাদা করে blast radius কমায়। Graceful degradation কম গুরুত্বপূর্ণ feature বাদ দিয়ে core কাজ চালায়।

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

জাহাজে আলাদা watertight compartment থাকলে এক অংশের পানি সব অংশ ডোবায় না। Circuit breaker ক্ষতিগ্রস্ত pump-এ বারবার বিদ্যুৎ দেওয়া থামায়। কিন্তু যাত্রী গণনার safety system বন্ধ করে “সব ঠিক” বলা graceful degradation নয়।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Circuit breaker-এর তিন state বুঝুন

Diagram-এর text flow দেখুন

stateDiagram-v2
 Closed --> Open: Failure threshold reached
 Open --> HalfOpen: Cooldown elapsed
 HalfOpen --> Closed: Probe succeeds
 HalfOpen --> Open: Probe fails

Closed state failure rate বা count মাপে। Threshold পার হলে open calls fail fast করে। Cooldown-এর পরে half-open অল্প probe দেয়, সব traffic একসঙ্গে নয়। Recovery confirm হলে closed হয়। Threshold window ও error classification workload অনুযায়ী নির্ধারিত।

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

নিচের Laravel fragment optional recommendation-এর timeout ও fallback দেখায়, সম্পূর্ণ distributed circuit breaker নয়। Atomic shared state ও probe coordination ছাড়া Cache counter দিয়ে production breaker বানানো ঠিক নয়। Separate queue worker pool bulkhead-এর ব্যবহারিক অংশ।

use Illuminate\Support\Facades\Http;
use Illuminate\Support\Facades\Log;

$recommendations = [];
try {
    $reply = Http::connectTimeout(1)->timeout(1)
        ->get(config('services.recommendations.url').'/products', [
            'customer_id' => $request->user()->id,
        ]);
    $reply->throw();
    $recommendations = $reply->json('items', []);
} catch (Throwable $exception) {
    Log::warning('recommendations.degraded', [
        'error_type' => $exception::class,
    ]);
}
return view('checkout', ['recommendations' => $recommendations]);

এটি PHP 8.3+ ও Laravel 12-এর শিক্ষামূলক fragment; সম্পূর্ণ application নয়। সংশ্লিষ্ট route-এ authentication ও resource authorization প্রয়োগ করতে হবে। নিচের অনুশীলনে failure ইচ্ছা করে তৈরি করুন; শুধু সফল response দেখে correctness ধরে নেবেন না।

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

Fail-fast resource বাঁচায় এবং outage cascade কমায়। ভুল threshold healthy dependency-ও block করতে পারে; breaker state observability দরকার। Fallback user experience বাঁচায়, কিন্তু stale price দিয়ে payment approve করা যাবে না। Critical ও optional dependency আলাদা করুন।

সাধারণ ভুল

Circuit breaker-কে retry-এর আরেক নাম বলা।
সব exception ধরে payment failure-ও success দেখানো।
Half-open-এ unlimited callers পাঠিয়ে recovery server overload করা।

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

প্রতি app instance-এর breaker local হলে state ভিন্ন হতে পারে; shared breaker coordination খরচ আনে। Bulkhead-এ worker pool, connection limit ও queue capacity পৃথক করা যায়। Fallback নিজে expensive database query হলে নতুন bottleneck তৈরি করতে পারে।

Recommendation service বন্ধ করে checkout latency মাপুন। Core order flow চলা চাই এবং degraded feature visible log-এ থাকবে। Recovery-তে probe count সীমিত করুন। Queue isolation test-এ bulk recommendation backlog যেন payment worker capacity না খায়।

মনে রাখুন

Breaker repeated calls থামায়।
Bulkhead resource আলাদা করে।
Fallback business সত্য বদলাবে না।

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

এক checkout dependency map-এ payment, recommendations ও email চিহ্নিত করুন। কোনটিতে fail closed, fallback বা async queue বেছে নেবেন ব্যাখ্যা করুন।

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

1. Retry আর breaker?

Retry আবার চেষ্টা করে; open breaker সাময়িকভাবে চেষ্টা থামিয়ে resource বাঁচায়।

2. Half-open কেন?

Recovery পরীক্ষা করতে অল্প traffic দেয়, একসঙ্গে সব call ছাড়ে না।

3. Bulkhead কী?

Resource isolation; এক workload-এর saturation অন্য critical workload-এর pool শেষ করতে পারে না।

4. Fallback সবখানে?

না। ভুল balance বা authorization দিয়ে success দেখানো safety ভাঙে।

5. Snippet পূর্ণ breaker?

না। এটি bounded optional dependency ও degradation; full breaker state machine আলাদা implementation চাই।

এই পাঠের কুইজ

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

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

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

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

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