তিনটি Guided Mock: URL Shortener, Chat ও Payment
Three Guided Mock Interviews
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- তিন problem-এর ভিন্ন correctness কেন্দ্র তুলনা
- Guided mock-এর আগে নিজের answer তৈরি
- Cross-case pattern transfer এবং overgeneralization এড়ানো
সমস্যা দিয়ে শুরু
URL shortener, chat ও payment—তিনটির diagram-এ API, database, cache থাকতে পারে। তাই একই memorized architecture কপি করা সহজ। কিন্তু shortener-এ hot redirect, chat-এ durable ordering/sync, payment-এ uncertain side effect এবং ledger প্রধান। এই lesson তিন guided exercise-এর তুলনামূলক overview; পরের dedicated mock lessons পূর্ণ sample response দেয়। Sample মুখস্থ করার আগে নিজের constraints লিখে design করুন।
সহজ করে বুঝি
প্রতিটি mock চার pass-এ করুন: scope, end-to-end flow, one deep dive এবং failure review। Shortener-এ create/redirect ratio ও disable freshness দেখুন। Chat-এ accepted/delivered/read এবং reconnect cursor দেখুন। Payment-এ stable operation key, signed events এবং reconciliation দেখুন। Common patterns reusable, কিন্তু accepted consistency ও failure response এক problem থেকে অন্যটিতে blindly সরানো যায় না।
পরিচিত একটি উপমা
তিনটি রান্নায় একই হাঁড়ি লাগে বলেই recipe এক নয়। Rice, soup এবং cake-এর heat ও timing আলাদা। Component vocabulary শেখা utensil চেনা; problem-specific invariant হলো recipe বোঝা।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD P[Shared design method] --> U[URL shortener] P --> C[Chat] P --> M[Payment] U --> UH[Hot reads and revocation] C --> CH[Durability order and sync] M --> MH[Idempotency ledger reconciliation] UH --> R[Compare justified tradeoffs] CH --> R MH --> R
একই method তিন scope-এ যায়। Branch-এর শেষে problem-specific high-risk area দেখুন। Review-এ কোন pattern shared এবং কোনটি আলাদা বলুন। Queue shortener analytics-এ lossy হতে পারে, payment ledger event-এ একই loss acceptable নয়। Cache chat presence-এ approximate হতে পারে, confirmed payment amount-এ authoritative নয়।
PHP ও Laravel-এ প্রয়োগ
Laravel/Pest feature-test fragment একটি chat acceptance contract যাচাই করে। Conversation ও User factories, membership relationship এবং message endpoint application-এ বাস্তবায়িত আছে ধরে নেওয়া হয়েছে। একই client_message_id retry-এ একই logical message ফেরত দিতে হবে। এটি database uniqueness ও controller behavior test করবে; recipient delivery বা payment integration পরীক্ষা করে না। প্রকল্পে এই chat backend bundled নেই, তাই snippet syntax-check ছাড়া integration-tested দাবি করা হচ্ছে না।
use App\Models\Conversation;
use App\Models\User;
test('same chat send operation is accepted once', function () {
$user = User::factory()->create();
$conversation = Conversation::factory()->create();
$conversation->members()->attach($user);
$payload = ['client_message_id' => 'send-001', 'body' => 'হ্যালো'];
$url = "/conversations/{$conversation->id}/messages";
$this->actingAs($user)->postJson($url, $payload)->assertSuccessful();
$this->actingAs($user)->postJson($url, $payload)->assertSuccessful();
$this->assertDatabaseCount('messages', 1);
});সুবিধা, সীমাবদ্ধতা ও trade-off
Guided example beginner-কে structure দেয়, কিন্তু answer পড়ে recognition-কে skill ভাবার ঝুঁকি থাকে। নিজে blank page-এ design করে পরে compare করুন। একই prompt repeat improvement দেখায়, নতুন constraint adaptation শেখায়। Sample architecture একমাত্র সঠিক solution নয়; alternative একই requirements পূরণ করলে sound হতে পারে। Reasoning না বুঝে scale number কপি করবেন না।
সাধারণ ভুল
- তিন case-এ একই consistency requirement ধরা।
- Sample answer পড়াকেই completed mock বলা।
- Provider timeout-কে সাধারণ cache miss-এর মতো handle করা।
আরও একটু গভীরে
Second round-এ নতুন condition যোগ করুন: shortener-এর link private, chat end-to-end encrypted, payment multi-currency। কোন data path ও security assumption বদলায় লিখুন। প্রতিটি change-এর complexity cost আছে। Interviewer hint পেলে design revise করার practice করুন। Dedicated mock response-এর পরে নিজের deviation explain করুন, identical diagram বানানোর চেষ্টা নয়।
মনে রাখুন
এক method reusable; shortener, chat ও payment-এর invariant আলাদা, তাই প্রতিটি mock problem-specific reasoning চাই।
নিজে চেষ্টা করুন
তিনটি ৪৫ মিনিট rehearsal আলাদা দিনে করুন। শেষে rubric অনুযায়ী দুটি gap নোট করুন। Dedicated sample পড়ে একটি justified difference এবং একটি ভুল assumption বের করুন। নতুন constraint দিয়ে revised diagram আবার আঁকুন।
নিজের বোঝা যাচাই করুন
1. তিন diagram মিললে solution এক?
না। Shared components ভিন্ন promise পূরণ করে। Data authority ও failure semantics আলাদা।
2. Sample আগে পড়ব?
Beginner orientation নিতে পারেন; real rehearsal-এ আগে নিজের scope ও answer লিখলে gap স্পষ্ট হয়।
3. সব event reliable চাই?
Business consequence অনুযায়ী। Analytics loss এবং financial ledger loss সমান নয়।
4. Practice-এর measure কী?
Coherent flow, invariant, justified trade-off ও failure recovery evidence। শুধু দ্রুত diagram আঁকা নয়।
5. ভিন্ন solution ভুল?
অবশ্যই নয়। Requirements, failure model এবং cost যুক্তিসহ পূরণ করছে কি না দেখুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।