Interview Trade-off: সিদ্ধান্ত ও failure scenario ব্যাখ্যা
Trade-offs and Failure Scenarios
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Decision-কে requirement ও failure model দিয়ে justify করা
- Consistency/availability ভাষা সঠিক ব্যবহার
- Retry, cache ও replication-এর costs প্রকাশ
সমস্যা দিয়ে শুরু
Candidate বললেন Redis সব query দ্রুত করে, microservices সব scale করে এবং CAP-এ দুইটি বেছে নিতে হয়। Interviewer partition ঘটালে order acceptance কী হবে জিজ্ঞেস করলেন; answer নেই। Trade-off discussion slogan নয়। নির্দিষ্ট workload, operation এবং failure condition-এ কী লাভ, কী sacrifice এবং কী mitigation হবে তা বলতে হয়।
সহজ করে বুঝি
Decision statement-এর উপযোগী রূপ: এই requirement-এর জন্য A নিচ্ছি, কারণ X; বিনিময়ে Y risk, তাই Z mitigation। CAP network partition-এর সময় consistency ও availability contract নিয়ে; normal latency/cost-এর সব choice তার মধ্যে ফেলা ভুল। Different operation-এর tolerance ভিন্ন হতে পারে: cached catalog stale চলতে পারে, oversold ticket নয়। User-visible failure behavior explicitly বলুন।
পরিচিত একটি উপমা
দ্রুত ferry এবং দীর্ঘ bridge route-এর choice weather, deadline ও cargo-র উপর বদলায়। সব সময় একটি সেরা route নেই। Storm-এর সময় route বন্ধ হলে customer-কে কী promise করবেন তা আগেই জানা trade-off-এর অংশ।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR R[Requirement and failure model] --> A[Option A] R --> B[Option B] A --> C[Compare latency correctness cost] B --> C C --> D[Choose with explicit sacrifice] D --> M[Mitigation and validation]
প্রথমে requirement ও assumed failure লিখুন। দুটি realistic option নিন। Latency, correctness, operational cost এবং recovery তুলনা করুন। Choice-এর sacrificed property বলুন, mitigation সেই sacrifice কতটুকু bound করে স্পষ্ট করুন। Requirement বদলালে decision কোন point-এ বদলাবেন সেটিও বলুন। সব comparison exact numbers চায় না, কিন্তু invent করা benchmark চলবে না।
PHP ও Laravel-এ প্রয়োগ
Laravel stale catalog fallback-এর simplified fragment। Cached product public, bounded TTL এবং authoritative checkout price revalidation আছে ধরে নেওয়া হয়েছে। Redis available থাকা অবস্থায় database transient failure হলে cached value কাজে লাগতে পারে; cache outage-এর complete fallback নয়। Sensitive inventory/payment status-এর জন্য একই policy blindভাবে ব্যবহার করবেন না।
use App\Models\Product;
use Illuminate\Support\Facades\Cache;
$product = Cache::get("catalog:{$productId}");
if ($product === null) {
$product = Product::query()->where('is_public', true)
->findOrFail($productId);
Cache::put("catalog:{$productId}", $product, 60);
}সুবিধা, সীমাবদ্ধতা ও trade-off
Stale reads availability ও speed সাহায্য করে, freshness কমায়। Strong synchronous coordination correctness বাড়াতে পারে, partition বা latency cost আনে। Async queue request fast করে কিন্তু completion lag ও retry complexity বাড়ায়। Retry transient issue ঢাকে, overloaded dependency-তে pressure বাড়ায়। প্রতিটি choice-এর accepted risk product-specific; absolute সবসময় ভালো ভাষা এড়ান।
সাধারণ ভুল
- CAP-কে যেকোনো সময় তিনটির মধ্যে দুইটি নির্বাচন বলা।
- Latency gain-এর বিনিময়ে correctness loss আছে কি না না বলা।
- Fallback-এর data authority আলাদা না করা।
আরও একটু গভীরে
Failure matrix-এ cache down, DB slow, network partition এবং operator error আলাদা করুন। Fail-open public browse-এর জন্য acceptable হতে পারে; authorization failure-এ fail-open private data leak করতে পারে। Retry-এর outcome unknown হলে business idempotency ও reconciliation আলোচনা করুন। Multi-region choice-এ user proximity, write ownership, conflict resolution এবং failback cost আনুন। Technology choice বদলানোর trigger measurable করুন।
মনে রাখুন
Trade-off answer-এ requirement, chosen option, sacrifice, mitigation ও failure behavior একসঙ্গে বলুন; slogan evidence নয়।
নিজে চেষ্টা করুন
Ticket booking এবং product catalog-এর consistency policy তুলনা করুন। Network partition-এ কোন request reject করবেন, কোন stale read দেবেন এবং user-কে কী জানাবেন লিখুন। প্রতিটি সিদ্ধান্তের operational cost বলুন।
নিজের বোঝা যাচাই করুন
1. একটি best database আছে?
সব workload-এর জন্য নয়। Access pattern, invariant, scale ও operational skill choice নির্ধারণ করে।
2. Cache free speed?
না। Invalidation, freshness, memory ও outage fallback cost আছে। Data type অনুযায়ী tolerance বদলায়।
3. Fail-open সবসময় ভালো?
Availability বাড়লেও abuse বা privacy risk হতে পারে। Authorization ও financial boundary-তে বিশেষ সতর্কতা দরকার।
4. Retry guarantee দেয়?
না। Duplicate work ও unknown outcome হতে পারে। Budget, idempotency এবং reconciliation লাগে।
5. Requirement বদলালে?
Decision trigger ব্যাখ্যা করুন। Original assumption ভুল হলে architecture revise করা sound reasoning।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।