Interview Deep Dive: HLD থেকে bottleneck বিশ্লেষণ
HLD and Bottleneck Deep Dive
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- HLD arrow থেকে risky path নির্বাচন
- Bottleneck hypothesis ও alternative তুলনা
- Concurrency এবং failure-এর concrete sequence বলা
সমস্যা দিয়ে শুরু
একটি feed architecture-এ cache, database ও queue আছে। Interviewer জিজ্ঞেস করলেন celebrity post এলে কী হয়। Candidate শুধু auto scale বললেন। Deep dive-এ box নামের বদলে operation count, data ownership এবং contention বোঝাতে হয়। কোন path dominant, কোথায় work amplification এবং failure হলে user কী দেখবেন—এগুলো দেখালেই high-level diagram বাস্তব design-এ রূপ নেয়।
সহজ করে বুঝি
একটি bottleneck নির্বাচন করুন requirement ও estimate থেকে: hot-key read, locked stock write, fan-out queue বা slow provider। Normal sequence বলুন, constrained resource identify করুন, overload sequence আঁকুন। তারপর দুই alternative তুলনা করুন। Chosen solution-এর নতুন risk এবং measurement বললে analysis বন্ধ হয় না, validate করার পথও পাওয়া যায়। Every bottleneck sharding দিয়ে solve হয় না।
পরিচিত একটি উপমা
Traffic jam-এর map-এ সব road আঁকা HLD। একটি bridge-এ কত lane, কোন সময় queue এবং alternative route কী deep dive। পুরো শহরে lane বাড়ানোর আগে bridge কেন jam করছে তা মাপা জরুরি।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD H[High level request path] --> E[Estimate dominant work] E --> B[Choose bottleneck] B --> S[Normal and failure sequence] S --> A[Compare alternatives] A --> C[Chosen change] C --> M[Measure gain and new limit]
HLD থেকে operation path নির্বাচন হয়। Estimate repeated work বা limited lock resource দেখায়। Sequence race ও wait প্রকাশ করে। Alternative-এ cache, batching বা data model change হতে পারে। Chosen change-এর পরে latency, error, resource এবং correctness measure করুন। Bottleneck অন্য component-এ সরলে diagram ও capacity claim update করতে হবে।
PHP ও Laravel-এ প্রয়োগ
Laravel catalog service fragment N+1 deep dive-এর জন্য। Product/category relationship আছে, current user public catalog দেখতে পারেন, result bounded। Eager loading repeated query কমাতে পারে; query count ও memory change মাপতে হবে। বড় relationship সব load করে universal performance win দাবি করা যাবে না।
use App\Models\Product;
$products = Product::query()
->where('is_public', true)
->with('category:id,name')
->select(['id', 'category_id', 'name'])
->orderBy('id')
->paginate(20);সুবিধা, সীমাবদ্ধতা ও trade-off
এক deep dive-এ যথেষ্ট depth reasoning দেখায়; খুব narrow optimization user goal ভুলে যেতে পারে। Cache quick win হলেও invalidation ও hot-key risk আনে। Denormalization read সহজ করে, update propagation জটিল করে। Faster query irrelevant হতে পারে যদি overall latency provider wait-এ যায়। End-to-end bottleneck এবং local improvement-এর পার্থক্য বলুন।
সাধারণ ভুল
- সমস্যা মাপার আগেই সব table shard করা।
- একটি fast query দেখিয়ে পুরো endpoint fast বলা।
- Alternative-এর নতুন correctness risk চেপে যাওয়া।
আরও একটু গভীরে
Sequence diagram-এ timeout-এর পরে unknown outcome, queue duplicate এবং stale reader দেখান। Lock contention হলে critical section length ও access ordering বলুন। Fan-out হলে recipient count এবং batch dispatch cost হিসাব করুন। Measurement plan representative data এবং concurrency ব্যবহার করবে; anecdotal local timing যথেষ্ট নয়। Deep dive শেষে HLD-তে ফিরে এই change পুরো design-এ কোথায় বসে তা explain করুন।
মনে রাখুন
Deep dive একটি risky arrow-কে concrete operation, bottleneck, alternative এবং validation plan-এ রূপ দেয়।
নিজে চেষ্টা করুন
নিজের URL shortener HLD থেকে একটি hot-key bottleneck বেছে নিন। Normal/miss/cache-outage sequence আঁকুন। Local cache, CDN ও request coalescing-এর দুই trade-off করে লিখুন এবং কোন metric দিয়ে সিদ্ধান্ত নেবেন বলুন।
নিজের বোঝা যাচাই করুন
1. Deep dive কোথায়?
Requirement ও estimate যেটিকে high-risk দেখায় সেখানে। Memorized topic চাপিয়ে না দিয়ে design-এর actual constraint বেছে নিন।
2. সব scaling sharding?
না। Query, batching, caching, admission control বা simpler data model যথেষ্ট হতে পারে।
3. Local benchmark যথেষ্ট?
না। Representative data, concurrency এবং downstream dependencies না মিললে conclusion সীমিত।
4. Alternative বলব কেন?
Choice-এর কারণ ও cost বোঝা যায়। শুধু technology নাম বললে trade-off reasoning দেখা যায় না।
5. শেষে কী করব?
Changed path HLD-তে যুক্ত করে নতুন risk ও validation metric summarize করুন। Deep dive যেন disconnected lecture না হয়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।