System Design কী ও কেন
What Is System Design?
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- System Design কোন ধরনের সমস্যা সমাধান করে
- Component ও data flow চেনা
- প্রয়োজন অনুযায়ী architecture বেছে নেওয়া
সমস্যা দিয়ে শুরু
আপনি Laravel দিয়ে একটি বইয়ের দোকান বানিয়েছেন। প্রথমে product দেখা ও order দেওয়া ঠিকমতো চলে। একদিন একটি জনপ্রিয় বই প্রকাশের সময় অনেক ক্রেতা একসঙ্গে আসেন। পেজ ধীর হয়, একই বইয়ের শেষ কপিটি দুজন কিনে ফেলেন, আর payment সফল হলেও email যায় না। এগুলো শুধু controller-এর code ছোট করে সমাধান করা যাবে না। কোন কাজ কোথায় হবে এবং ব্যর্থ হলে কী হবে—সেই নকশা দরকার।
সহজ করে বুঝি
System Design হলো একটি software system-এর অংশ, তাদের দায়িত্ব, ডেটার অবস্থান এবং যোগাযোগের পথ নির্ধারণ করা। এতে database বেছে নেওয়া আছে, আবার কতটুকু consistency দরকার সেটিও আছে। ভালো design শুরু হয় “কী সমস্যা মেটাব?” প্রশ্ন দিয়ে। “কোন technology ব্যবহার করব?” প্রশ্নটি পরে আসে।
একটি component diagram সম্পূর্ণ design নয়। প্রতিটি arrow-এর অর্থ বলতে হবে: synchronous HTTP call, database query, নাকি asynchronous message? কে timeout সামলাবে? ডেটা কোন অংশের মালিকানায় থাকবে? এগুলো ব্যাখ্যা করতে পারলেই diagram কাজে লাগে।
পরিচিত একটি উপমা
একটি ছোট রেস্তোরাঁয় একজনই order নেন, রান্না করেন ও bill করেন। ক্রেতা বাড়লে cashier, kitchen ও delivery আলাদা হতে পারে। কিন্তু শুরুতেই দশটি আলাদা kitchen করলে খরচ ও coordination বাড়বে। Software-এও একই কথা: প্রথমে যথেষ্ট সহজ নকশা, তারপর মাপা সমস্যার জন্য পরিবর্তন।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD A[Customer] -->|HTTP| B[Laravel App] B -->|Read and write| C[(PostgreSQL)] B -->|Dispatch after commit| D[Queue] D --> E[Email Worker]
১. Customer request পাঠান। ২. Laravel validation ও business rule চালায়। ৩. Database-এ order লেখা হয়। ৪. Commit-এর পরে email job dispatch হয়। ৫. Worker পরে কাজটি করে। এই সরল flow-তেই data correctness এবং user-facing response-এর সময় আলাদা করে ভাবা হয়েছে।
PHP ও Laravel-এ প্রয়োগ
নিচের snippet একটি Eloquent Order model ও SendOrderReceipt job আছে ধরে নেওয়া controller method। এটি payment সম্পন্ন করার code নয়। Client-এর দেওয়া price বিশ্বাস করা যাবে না; বাস্তবে server থেকে product price নিয়ে total হিসাব করতে হবে।
use App\Jobs\SendOrderReceipt;
use App\Models\Order;
use Illuminate\Support\Facades\DB;
$order = DB::transaction(function () use ($user) {
$order = Order::create([
'user_id' => $user->id,
'status' => 'pending',
]);
SendOrderReceipt::dispatch($order->id)->afterCommit();
return $order;
});
return response()->json(['id' => $order->id], 201);সুবিধা, সীমাবদ্ধতা ও trade-off
একটি application ও একটি database দিয়ে শুরু করলে deployment এবং debugging সহজ। Queue দিলে response দ্রুত ফিরতে পারে, কিন্তু worker, retries ও failed jobs দেখতে হবে। শুধু queue ব্যবহার করলেই কাজ কখনও হারাবে না—এমন নিশ্চয়তা তৈরি হয় না। গুরুত্বপূর্ণ notification-এর জন্য পরে outbox pattern দরকার হতে পারে।
সাধারণ ভুল
- ব্যবহারকারীর সংখ্যা না জেনেই microservices বেছে নেওয়া।
- Email পাঠানোকে order transaction-এর মধ্যে দীর্ঘ সময় ধরে রাখা।
- Diagram-এ database আঁকা কিন্তু schema বা data ownership না ভাবা।
- “Scalable” বলা, অথচ কোন bottleneck বদলাবে তা না বলা।
আরও একটু গভীরে
একটি design-এর মান বিচার করুন business outcome দিয়ে। দশ সেকেন্ড দেরিতে receipt যাওয়া গ্রহণযোগ্য হতে পারে; ভুল total charge করা নয়। কোন failure গ্রহণযোগ্য এবং কোনটি নয়, সেটিই আপনার consistency, latency ও cost-এর সিদ্ধান্ত পরিচালনা করবে। Distributed system বাড়ালে network failure-এর নতুন সম্ভাবনাও বাড়ে।
মনে রাখুন
- Requirements আগে, technology পরে।
- প্রতিটি component-এর দায়িত্ব ও প্রতিটি arrow-এর অর্থ স্পষ্ট করুন।
- সবচেয়ে ছোট কার্যকর design দিয়ে শুরু করুন।
নিজে চেষ্টা করুন
একটি অনলাইন লাইব্রেরির জন্য পাঠক, Laravel app, database এবং notification worker আঁকুন। বই ধার দেওয়ার কোন ধাপ ব্যর্থ হলে ধারটি বাতিল হবে, আর কোন ধাপ পরে retry করা যাবে—লিখুন।
নিজের বোঝা যাচাই করুন
1. System Design কি শুধু database নির্বাচন?
না। এতে requirements, component boundaries, data flow, failure handling ও operational trade-off একসঙ্গে বিবেচনা করা হয়।
2. শুরুতেই microservices দরকার?
না। ছোট team ও সীমিত scale-এ modular monolith অনেক সময় যথেষ্ট। আলাদা deployment-এর বাস্তব প্রয়োজন হলে split ভাবুন।
3. Email কেন queue-তে?
ব্যবহারকারীকে mail server-এর জন্য অপেক্ষা করাতে না চাইলে। তবে eventual delivery দেখতে retry ও monitoring লাগে।
4. Arrow-এ label কেন দরকার?
যোগাযোগের ধরন বোঝা যায়। HTTP call আর queue message-এর timing ও failure behavior আলাদা।
5. ভালো design-এর প্রথম input কী?
ব্যবহারকারীর কাজ, correctness-এর শর্ত এবং latency, availability, cost-এর মতো মানগত লক্ষ্য।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।