HLD ও LLD: বড় নকশা থেকে বিস্তারিত নকশা
High-Level and Low-Level Design
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- High-level ও low-level design আলাদা করা
- একই সমস্যাকে দুই স্তরে ব্যাখ্যা করা
- Boundary থেকে class দায়িত্ব নির্ধারণ
সমস্যা দিয়ে শুরু
আপনি order service design review-তে সব controller method দেখালেন। কিন্তু payment provider down হলে কী হবে কেউ বুঝল না। আরেক review-তে শুধু পাঁচটি box আঁকলেন; stock কীভাবে একবার কমবে তার উত্তর নেই। দুই ক্ষেত্রেই design-এর একটি প্রয়োজনীয় স্তর বাদ গেছে।
সহজ করে বুঝি
High-Level Design বা HLD প্রধান component, data store, communication ও deployment boundary দেখায়। Low-Level Design বা LLD সেই boundary-র ভিতরের data structure, class, interface, state transition এবং algorithm ব্যাখ্যা করে।
এরা আলাদা সময়ে শেষ করে ফেলার দুই document নয়। LLD-তে যদি বোঝা যায় একটি operation atomic হতে হবে, HLD-র database boundary বদলাতে হতে পারে। একইভাবে HLD-তে async queue বেছে নিলে LLD-তে retry-safe job contract লাগবে।
পরিচিত একটি উপমা
শহরের মানচিত্রে road, bridge ও hospital দেখা HLD-এর মতো। Hospital-এর emergency room-এর দরজা কোথায়, রোগী কোন desk থেকে কোথায় যাবেন—এটি LLD-এর কাছাকাছি। শহরের মানচিত্রে প্রতিটি chair আঁকলে বোঝা কঠিন; room plan-এ bridge না দেখালে সেটি ভুল নয়, কারণ তার scope আলাদা।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD A[Checkout API] --> B[Order Service] B --> C[(Orders and Stock)] B --> D[Receipt Queue] B -. Internal responsibility .-> E[PlaceOrder Action] E --> F[Validate and lock stock] E --> G[Persist order]
প্রথমে checkout boundary ও তার dependency দেখান। তারপর PlaceOrder action-এর input, output ও failure cases লিখুন। Controller HTTP-specific কাজ করবে, action business operation প্রকাশ করবে। শুধু class আলাদা করলেই distributed architecture তৈরি হয় না।
PHP ও Laravel-এ প্রয়োগ
নিচের controller method একটি PlaceOrder action ও StoreOrderRequest আছে ধরে নেওয়া illustrative snippet। Action-এর implementation-এ transaction, price calculation ও idempotency থাকবে; এই ছোট interface সেই guarantee নিজে বাস্তবায়ন করে না।
use App\Actions\PlaceOrder;
use App\Http\Requests\StoreOrderRequest;
public function store(StoreOrderRequest $request, PlaceOrder $placeOrder)
{
$order = $placeOrder->handle(
user: $request->user(),
productId: $request->integer('product_id'),
quantity: $request->integer('quantity'),
);
return response()->json(['id' => $order->id], 201);
}সুবিধা, সীমাবদ্ধতা ও trade-off
HLD দ্রুত overall risks প্রকাশ করে, কিন্তু code-level correctness প্রমাণ করে না। LLD implementation-এর ambiguity কমায়, কিন্তু অতিরিক্ত interface ও abstraction ছোট project-কে জটিল করতে পারে। Boundary ও invariants আগে স্থির করে কেবল পরিবর্তনশীল অংশে abstraction দিন।
সাধারণ ভুল
- HLD-তে unexplained arrow রেখে দেওয়া।
- Controller, service ও repository থাকা মানেই clean design ভাবা।
- LLD-তে transaction boundary না দেখানো।
- Business state ও HTTP status একই জিনিস মনে করা।
আরও একটু গভীরে
একটি order-এর pending → confirmed → shipped state machine একটি উপকারী LLD artifact। Invalid transition বন্ধ করতে database write condition বা lock লাগতে পারে। “Method ডাকা হয়েছে” আর “state transition স্থায়ী হয়েছে”—এই পার্থক্য স্পষ্ট রাখলে failures নিয়ে ভালো আলোচনা হয়।
মনে রাখুন
- HLD দেখায় অংশগুলোর সম্পর্ক, LLD দেখায় ভিতরের mechanism।
- দুই স্তর একে অন্যকে সংশোধন করতে পারে।
- Class সংখ্যা দিয়ে design-এর মান মাপবেন না।
নিজে চেষ্টা করুন
একটি refund flow-এর HLD আঁকুন। তারপর RefundOrder action-এর input, valid state transitions এবং provider timeout হলে outcome লিখুন।
নিজের বোঝা যাচাই করুন
1. LLD কি শুধু class diagram?
না। Schema, state machine, concurrency rules, interface ও algorithm-ও এর অংশ।
2. HLD-তে SQL query দেখাতে হবে?
প্রথমে নয়। Query যদি প্রধান bottleneck বা correctness concern হয়, deep dive-এ দেখান।
3. Action class কি microservice?
না। এটি একই Laravel application-এর একটি class হতে পারে।
4. কখন design-এর স্তর বদলাবেন?
বর্তমান স্তরে একটি গুরুত্বপূর্ণ প্রশ্নের উত্তর না মিললে। যেমন overall flow থেকে stock locking-এর গভীরে যাওয়া।
5. Interface সবখানে কেন নয়?
প্রতিটি abstraction বোঝা ও maintenance-এর খরচ যোগ করে। প্রকৃত boundary বা বিকল্প implementation থাকলে বেশি কাজে লাগে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।