System Design কী এবং কেন গুরুত্বপূর্ণ

What is system design & why it matters

৯ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

System Design মানে একটি সফটওয়্যার সিস্টেমের বিভিন্ন অংশ (সার্ভার, ডেটাবেস, ক্যাশ, নেটওয়ার্ক) কীভাবে একসাথে কাজ করবে তা পরিকল্পনা করা — যাতে সিস্টেমটি লক্ষ লক্ষ ইউজারের জন্য স্কেলেবল, রিলায়েবল ও দ্রুত থাকে।
প্রতিটি সিস্টেমের দুই ধরনের রিকোয়ারমেন্ট থাকে — ফাংশনাল (সিস্টেম কী করে) ও নন-ফাংশনাল (সিস্টেম কতটা ভালোভাবে করে — স্কেল, স্পিড, রিলায়েবিলিটি)। নন-ফাংশনাল রিকোয়ারমেন্টই আসলে পুরো আর্কিটেকচার ঠিক করে দেয়।
"স্কেল মাইন্ডসেট" — ১,০০০ ইউজারের জন্য যা কাজ করে, তা ১ কোটি ইউজারে ভেঙে পড়তে পারে। এই কোর্স সেই ভাঙন কোথায়, কেন হয়, এবং কীভাবে প্রতিরোধ করা যায় তা শেখায়।
এই কোর্স DSA (অ্যালগরিদমিক বিল্ডিং ব্লক) ও DBMS (একটি ডেটাবেস কীভাবে কাজ করে) কোর্সের উপর ভিত্তি করে — এখন শিখব কীভাবে অনেকগুলো মেশিন, ডেটাবেস ও সার্ভিস একত্র করে একটি সুসংগত সিস্টেম বানাতে হয়।

এই পাঠে যা শিখবেন

System Design অ্যালগরিদম ডিজাইন (DSA) ও ডেটাবেস ডিজাইন (DBMS) থেকে ঠিক কীভাবে আলাদা
ফাংশনাল বনাম নন-ফাংশনাল রিকোয়ারমেন্টের পার্থক্য এবং কেন নন-ফাংশনাল রিকোয়ারমেন্ট আর্কিটেকচার ঠিক করে দেয়
"স্কেল মাইন্ডসেট" — কেন ছোট স্কেলে কাজ করা ডিজাইন বড় স্কেলে ভেঙে পড়ে
Python দিয়ে একটি সাধারণ QPS (queries per second) হিসাব — L02-এর ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশনের প্রথম স্বাদ

১ · System Design কীভাবে DSA ও DBMS থেকে আলাদা

System DesignSystem Designএকটি সফটওয়্যার সিস্টেমের কম্পোনেন্টগুলো (সার্ভার, ডেটাবেস, ক্যাশ, নেটওয়ার্ক, মেসেজ কিউ) কীভাবে সংগঠিত হবে এবং একসাথে কাজ করবে তার উচ্চ-স্তরের পরিকল্পনা — নির্দিষ্ট কোনো একটি অ্যালগরিদম বা ডেটাবেস স্কিমা নয়, বরং পুরো সিস্টেমের আর্কিটেকচার। হলো একটি সম্পূর্ণ সফটওয়্যার সিস্টেমের উচ্চ-স্তরের আর্কিটেকচার পরিকল্পনা করা। এটি DSA বা DBMS-এর বিকল্প নয় — বরং তাদের উপর তৈরি একটি নতুন স্তর।

DSA (আগের কোর্স)
একটি একক প্রোগ্রামে একটি সমস্যা কীভাবে সবচেয়ে দক্ষভাবে সমাধান করা যায় — কোন ডেটা স্ট্রাকচার, কোন অ্যালগরিদম, কোন Big-O।

DBMS (আগের কোর্স)
একটি একক ডেটাবেসের ভেতরে ডেটা কীভাবে সংরক্ষিত, ইনডেক্সড ও কোয়েরি করা হয়।

System Design (এই কোর্স)
অনেকগুলো সার্ভার, ডেটাবেস, ক্যাশ ও সার্ভিস একত্র করে এমন একটি সিস্টেম বানানো যা ১ কোটি ইউজারকেও নির্ভরযোগ্যভাবে সার্ভ করতে পারে।

মূল পার্থক্য

DSA আপনাকে শেখায় একটি ফাংশন কতটা দ্রুত চলবে (L41, discrete-math কোর্স দেখুন)। System Design আপনাকে শেখায় যখন সেই ফাংশনটি প্রতি সেকেন্ডে ১০,০০০ বার, ১০০টি ভিন্ন সার্ভার থেকে, একসাথে কল হয় — তখন পুরো সিস্টেমটি কীভাবে ভেঙে না পড়ে চলবে।

২ · ফাংশনাল বনাম নন-ফাংশনাল রিকোয়ারমেন্ট

যেকোনো সিস্টেম ডিজাইনের প্রথম ধাপ হলো রিকোয়ারমেন্ট বোঝা — এবং রিকোয়ারমেন্ট দুই ধরনের। ফাংশনাল রিকোয়ারমেন্টFunctional Requirementsসিস্টেমটি আসলে কী কী কাজ করবে তার তালিকা — যেমন "ইউজার পোস্ট করতে পারবে", "ইউজার ফলো করতে পারবে"। বলে সিস্টেমটি কী করবে — যেমন একটি সোশ্যাল মিডিয়া অ্যাপে "ইউজার পোস্ট করতে পারবে", "ইউজার অন্য ইউজারকে ফলো করতে পারবে", "ইউজার তার ফিড দেখতে পারবে"। নন-ফাংশনাল রিকোয়ারমেন্টNon-Functional Requirementsসিস্টেমটি কাজগুলো কতটা ভালোভাবে করবে তার মানদণ্ড — স্কেল, স্পিড, রিলায়েবিলিটি, কনসিস্টেন্সি, নিরাপত্তা, খরচ। বলে সিস্টেমটি কাজগুলো কতটা ভালোভাবে করবে — যেমন "১০ কোটি ডেইলি অ্যাক্টিভ ইউজার সাপোর্ট করতে হবে", "ফিড ২০০ মিলিসেকেন্ডের মধ্যে লোড হতে হবে", "৯৯.৯৯% আপটাইম থাকতে হবে"।

কেন নন-ফাংশনাল রিকোয়ারমেন্টই আসল খেলা

"ইউজার পোস্ট করতে পারবে" — এই ফাংশনাল রিকোয়ারমেন্টটি ১০০ ইউজার হোক বা ১০ কোটি, একই থাকে। কিন্তু "১০ কোটি ইউজার, প্রতি পোস্টে ২০০ms-এর মধ্যে রেসপন্স" — এই নন-ফাংশনাল রিকোয়ারমেন্টটাই ঠিক করে দেয় আপনার একটি সার্ভার লাগবে নাকি ১,০০০টি, একটি ডেটাবেস লাগবে নাকি শার্ডেড ক্লাস্টার, ক্যাশিং লাগবে কি না। এই কোর্সের প্রতিটি মডিউল আসলে বিভিন্ন নন-ফাংশনাল চ্যালেঞ্জ (স্কেল, লেটেন্সি, রিলায়েবিলিটি, কনসিস্টেন্সি) সমাধানের কৌশল।

৩ · "স্কেল মাইন্ডসেট" — কেন ছোট ডিজাইন বড় স্কেলে ভেঙে পড়ে

ধরুন আপনি একটি ফটো-শেয়ারিং অ্যাপ বানালেন — একটি সার্ভার, একটি MySQL ডেটাবেস, ছবি সরাসরি সার্ভারের ডিস্কে সেভ। ১০০ ইউজারের জন্য এটি নিখুঁতভাবে কাজ করবে। কিন্তু ইউজার ১ কোটি হলে কী হয়?

একটি সার্ভার প্রতি সেকেন্ডে হাজার হাজার রিকোয়েস্ট হ্যান্ডল করতে পারবে না — লোড ব্যালেন্সিং লাগবে (M3)।
একটি MySQL ডেটাবেস এত রাইট থ্রুপুট সামলাতে পারবে না — শার্ডিং ও রেপ্লিকেশন লাগবে (M4)।
একই ছবি বারবার ডিস্ক থেকে পড়া ধীরগতির — ক্যাশিং ও CDN লাগবে (M5)।
একটি বিশাল মনোলিথ সার্ভার আপডেট করা ও স্কেল করা কঠিন হয়ে যায় — মাইক্রোসার্ভিস ভাবতে হবে (M7)।

এই প্রতিটি ভাঙন-বিন্দু এবং তার সমাধান এই কোর্সের একটি নির্দিষ্ট মডিউলে বিস্তারিত কভার হবে। System Design শেখা মানে মূলত এই ভাঙন-বিন্দুগুলো আগে থেকে চেনা এবং প্রতিরোধ করার প্রমাণিত প্যাটার্ন জানা।

একটি সাধারণ স্কেলড সিস্টেমে রিকোয়েস্টের পথ — এই কোর্সের প্রতিটি বক্স একটি নির্দিষ্ট মডিউলের বিষয়বস্তু।

৪ · প্রথম হিসাব — QPS (Queries Per Second) অনুমান করা

System Design আলোচনা প্রায় সবসময় সংখ্যা দিয়ে শুরু হয় — কতজন ইউজার, প্রতিজন কতবার রিকোয়েস্ট করে, তাই দিয়ে গড় ও পিক QPS বের করা যায়। এটি L02-এ বিস্তারিত কভার হবে, কিন্তু এখানে একটি সহজ প্রিভিউ দেখি —

Python

daily_active_users = 10_000_000      # ১ কোটি DAU
requests_per_user_per_day = 20        # গড়ে প্রতিজন প্রতিদিন ২০টি রিকোয়েস্ট করে
seconds_per_day = 24 * 60 * 60        # ৮৬,৪০০ সেকেন্ড

total_requests_per_day = daily_active_users * requests_per_user_per_day
avg_qps = total_requests_per_day / seconds_per_day

peak_factor = 3   # পিক আওয়ারে ট্রাফিক গড়ের চেয়ে ~৩ গুণ বেশি হয়, এটি একটি সাধারণ অনুমান
peak_qps = avg_qps * peak_factor

print(f"মোট রিকোয়েস্ট/দিন: {total_requests_per_day:,}")
print(f"গড় QPS: {avg_qps:,.1f}")
print(f"পিক QPS (~{peak_factor}x): {peak_qps:,.1f}")

লক্ষ্য করুন — গড় QPS (~২,৩১৫) দিয়ে সার্ভার ডিজাইন করলে পিক আওয়ারে (~৬,৯৪৪ QPS) সিস্টেম ভেঙে পড়বে। এই কারণেই System Design-এ সবসময় পিক লোড ধরে ক্যাপাসিটি প্ল্যান করা হয়, গড় লোড ধরে নয় — L02-এ এই হিসাবের পূর্ণ পদ্ধতি (স্টোরেজ, ব্যান্ডউইথ সহ) বিস্তারিত দেখব।

৫ · এই কোর্স ও DSA/DBMS কোর্সের সম্পর্ক

এই সাইটের DSA কোর্স শেখায় একটি অ্যালগরিদম কতটা দক্ষ, আর DBMS কোর্স শেখায় একটি ডেটাবেস কীভাবে ভেতরে কাজ করে। এই কোর্স ধরে নেয় আপনি এই দুটোই জানেন, এবং শেখায় কীভাবে অনেকগুলো সার্ভার, ডেটাবেস, ক্যাশ ও মেসেজ কিউ একত্র করে এমন একটি সিস্টেম বানাতে হয় যা বাস্তবে লক্ষ লক্ষ ইউজারকে সার্ভ করতে পারে। তিনটি কোর্স একসাথে একজন ইঞ্জিনিয়ারকে "কোড লেখা" থেকে "প্রোডাকশন-গ্রেড সিস্টেম ডিজাইন করা" পর্যন্ত পূর্ণ পথ দেখায়।

মূল কথা · Key takeaway

System Design কোনো একক "সঠিক উত্তর" খোঁজার বিষয় নয় — এটি ট্রেড-অফ বোঝার বিষয়। প্রতিটি সিদ্ধান্ত (SQL নাকি NoSQL, ক্যাশ করব নাকি না, স্ট্রং কনসিস্টেন্সি নাকি ইভেনচুয়াল) একটি ট্রেড-অফ, এবং সঠিক সিদ্ধান্ত নির্ভর করে আপনার নন-ফাংশনাল রিকোয়ারমেন্টের উপর। এই কোর্স শেষে আপনি এই ট্রেড-অফগুলো চিনতে ও যুক্তিসঙ্গতভাবে সিদ্ধান্ত নিতে পারবেন।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি সিস্টেম যা ১,০০০ ইউজারের জন্য নিখুঁতভাবে কাজ করে, কেন ১ কোটি ইউজারে গিয়ে ভেঙে পড়তে পারে — এমনকি কোনো "বাগ" ছাড়াই?

মূল উত্তর — রিসোর্স লিমিট ও বটলনেক। কোডে কোনো ভুল না থাকলেও, প্রতিটি রিসোর্সের (CPU, মেমরি, ডিস্ক I/O, নেটওয়ার্ক ব্যান্ডউইথ, ডেটাবেস কানেকশন) একটি সসীম ক্যাপাসিটি আছে। ১,০০০ ইউজারে যে লোড নগণ্য, ১ কোটি ইউজারে সেটাই একটি নির্দিষ্ট রিসোর্সকে (প্রায়ই ডেটাবেস) পুরোপুরি সম্পৃক্ত করে দেয় — এবং সেই একটি বটলনেক পুরো সিস্টেমকে ধীর বা অচল করে দেয়।

System Design শেখা মানে এই বটলনেকগুলো আগে থেকে চিহ্নিত করা (লোড টেস্টিং, ক্যাপাসিটি এস্টিমেশন দিয়ে) এবং প্রতিটির জন্য প্রমাণিত সমাধান (ক্যাশিং, শার্ডিং, লোড ব্যালেন্সিং) প্রয়োগ করা — বাগ ফিক্স করা নয়, বরং আর্কিটেকচার পরিবর্তন করা।

প্র ০২ ইন্টারভিউয়াররা System Design ইন্টারভিউতে ফাংশনাল রিকোয়ারমেন্টের চেয়ে নন-ফাংশনাল রিকোয়ারমেন্ট নিয়ে বেশি সময় ব্যয় করেন কেন?

কারণ ফাংশনাল রিকোয়ারমেন্ট ("ইউজার পোস্ট করতে পারবে") প্রায় যেকোনো স্কেলে একই থাকে এবং সাধারণত সহজ। কিন্তু নন-ফাংশনাল রিকোয়ারমেন্ট (কতজন ইউজার, কত লেটেন্সি, কত আপটাইম দরকার) সরাসরি ঠিক করে দেয় সিস্টেমটির প্রতিটি স্তরের ডিজাইন — এক সার্ভার নাকি হাজার, একটি ডেটাবেস নাকি শার্ডেড ক্লাস্টার। ভুল নন-ফাংশনাল অনুমানে ডিজাইন করলে হয় সিস্টেম ওভার-ইঞ্জিনিয়ার্ড (অপ্রয়োজনীয় খরচ) হবে, নয়তো আন্ডার-ইঞ্জিনিয়ার্ড (স্কেলে ভেঙে পড়বে) হবে।

প্র ০৩ এই কোর্স কেন DSA ও DBMS কোর্সের পরে আসে, আগে নয়?

System Design ধরে নেয় আপনি ইতিমধ্যে জানেন একটি অ্যালগরিদমের জটিলতা (DSA) কীভাবে বিশ্লেষণ করতে হয় এবং একটি একক ডেটাবেস (DBMS) ভেতরে কীভাবে কাজ করে — ইনডেক্সিং, নরমালাইজেশন, ট্রানজেকশন। এই কোর্স সেই জ্ঞানের উপর একটি নতুন স্তর যোগ করে: একাধিক সার্ভার ও ডেটাবেসকে কীভাবে একত্র করে একটি বড় সিস্টেম বানানো যায়। ভিত্তি ছাড়া এই স্তরে যাওয়া কঠিন — যেমন একটি ইটের গঠন না বুঝে একটি বহুতল ভবনের নকশা করা কঠিন।

অনুশীলন

চিন্তা করুন: আপনার প্রতিদিনের ব্যবহৃত একটি অ্যাপ (যেমন bKash, Pathao, Facebook) বেছে নিন এবং তার ৩টি ফাংশনাল ও ৩টি নন-ফাংশনাল রিকোয়ারমেন্ট অনুমান করে লিখুন।

উদাহরণ (bKash-এর মতো একটি পেমেন্ট অ্যাপ): ফাংশনাল — ইউজার টাকা পাঠাতে পারবে, ব্যালেন্স চেক করতে পারবে, লেনদেনের ইতিহাস দেখতে পারবে। নন-ফাংশনাল — প্রতিটি লেনদেন অবশ্যই সঠিক ও ধারাবাহিক (strong consistency) হতে হবে (একই টাকা দুবার কাটা যাবে না), ৯৯.৯৯% আপটাইম দরকার, এবং লেনদেন ৩ সেকেন্ডের মধ্যে সম্পন্ন হতে হবে।
হিসাব করুন: একটি অ্যাপের ৫০ লক্ষ (5,000,000) DAU এবং প্রতিজন গড়ে দিনে ১৫টি রিকোয়েস্ট করে। পিক ফ্যাক্টর ৪x ধরে গড় ও পিক QPS হাতে হিসাব করুন, তারপর উপরের কোড সেলে সংখ্যাগুলো বদলে মিলিয়ে দেখুন।

মোট রিকোয়েস্ট/দিন = ৫০,০০,০০০ × ১৫ = ৭,৫০,০০,০০০। গড় QPS = ৭,৫০,০০,০০০ / ৮৬,৪০০ ≈ ৮৬৮.১। পিক QPS (৪x) ≈ ৮৬৮.১ × ৪ ≈ ৩,৪৭২.২। এই সংখ্যাটিই ঠিক করে দেবে আপনার কতগুলো অ্যাপ সার্ভার ও কী ধরনের ডেটাবেস আর্কিটেকচার দরকার — L02-এ আরও গভীরে যাব।