সিস্টেম ডিজাইন কেন দরকার?

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

আমরা ধাপে ধাপে প্রতিটা প্রশ্নের উত্তর জানবো। সবগুলো প্রশ্নের উত্তর জানার পর আপনি সমস্যাটা বুঝে ফেলবেন। আর সমস্যার সমাধান করা শুরু করবো সেশন ০২ থেকে।

১ আমি ডিজাইন কেন করবো? শুধু কোড লিখলেই কি এনাফ না?
২ ঠিক আছে, লোড বাড়লে জিনিস ভেঙে যায়। কিন্তু আসলে ভাঙে টা কি?
৩ উফফ এতো এতো সমস্যা! এগুলোর কোনো জেনারালাইজড ফর্ম কি নেই?
৪ একটা সিস্টেম বড় হওয়ার সময় আসলে কীভাবে গ্রো করে?
৫ রিসোর্স বাড়িয়ে দিলেই সব সমস্যার সমাধান হয় না কেনো?
৬ "Fast" এর আসল মানে কী?

০১ আমি ডিজাইন কেন করবো?

ভাবুন, আপনি আপনার এলাকায় একটা ছোট চা দোকান খুললেন।

একজন (আপনি) চা বানান।
দিনে ২০ জন কাস্টমার আসে।
অর্ডার নেন, পানি ফুটান, চা ঢালেন, টাকা নেন, ব্যস এটুকুই। জীবন ফুরফুরা!
কোনো “সিস্টেম” দরকার নেই, শুধু আপনিই যথেষ্ট।

৫০ জন ইউজারের একটা অ্যাপ্লিকেশনের জন্যও ব্যাপারটা একই রকম। এক Server, এক Database, কোনো Complexity নেই। তাহলে System Design নামের জিনিসটার দরকারটা আসলে কোথায়?

কারণ একটাই

ইউজার বাড়লে সবকিছু আর ফুরফুরা থাকে না! আগের সেই সরল চেহারাটা পুরো পাল্টে যায়।

০২ লোড বাড়লে আসলে কী ভাঙে?

এখন ভাবুন, আপনার চা বিখ্যাত হয়ে গেল। প্রতি সকালে ৫,০০০ মানুষ আসছে।

কী কী আর সরল থাকবে না, আপনি নিজেই একটু ভাবুন তো?

কাস্টমার যতই বাড়ুক, পানি তো আর দ্রুত ফুটবে না (এক চুলা, এক কেতলি)।
লাইন এতো বড় হচ্ছে যে মানুষের ধৈর্যের সীমা ছাড়িয়ে যাচ্ছে, আর তারা চলে যাচ্ছে।
আপনি সব অর্ডার মনে রাখতে পারছেন না।
সকাল ৮টায় দুধ শেষ হয়ে যাচ্ছে।
একদিন আপনি অসুস্থ হলে পুরো দোকান বন্ধ।
টাকার হিসাবে ভুল হচ্ছে।

সফটওয়্যারেও ঠিক একই সমস্যাগুলো ঘটে

চা দোকানের সমস্যা	Software-এ এর সমতুল্য
পানি ফুটাতে দেরি	Server Slow (CPU/Memory limit)
লাইন বড় হওয়া	Request Time Out
দুধ শেষ	Database এর Space বা Connection শেষ
আপনি অসুস্থ হলে দোকান বন্ধ	Single Point of Failure (SPOF)
টাকার ভুল	Data Inconsistency

ঠিক এই জায়গাতেই “সিস্টেম ডিজাইন” এর আগমন। এটা এমন একটা ডিসিপ্লিন, যা আপনার সফটওয়্যারকে সেই দিনের জন্য প্রস্তুত রাখে, যেদিন অনেক মানুষ আসবে।

০৩ সমস্যার জেনারালাইজড ফর্মগুলো কী কী?

সবগুলো সমস্যা ভালোভাবে খেয়াল করলে ঘুরেফিরে তিনটা জিনিসের দেখা মেলে:

জিনিস Slow হয়ে যাচ্ছে (লাইন বড় হচ্ছে, response time বাড়ছে)।
জিনিস Break করছে (আপনি অসুস্থ, কোনো backup নেই)।
জিনিস Incorrect হচ্ছে (order ভুলে যাচ্ছেন, টাকার হিসেব মিলাতে পারছেন না)।

System Design এর মূল প্রশ্ন

“আরো বেশি মানুষ আমার সার্ভিস ইউজ করলেও কীভাবে এটাকে Fast, Reliable, আর Correct রাখব?”

ব্যস, মোটাদাগে এই তিনটাই মৌলিক সমস্যা। বাকি সব (Load Balancer, Database, Cache, Queue, Microservice) আসলে ভিন্ন ভিন্ন সমস্যা সমাধানের ভিন্ন ভিন্ন হাতিয়ার। সহজ করে বললে, চা দোকানের সমস্যাকে ইন্টারনেট স্কেলে সমাধান করার Tools।

০৪ একটা সিস্টেম কীভাবে গ্রো করে?

System কখনো “এক Server” থেকে এক লাফে “Facebook Scale” এ পৌঁছায় না। এটা ধাপে ধাপে, প্রেডিকটেবল স্টেজে বড় হতে থাকে।

১

চা দোকান

one customer at a time

কাস্টমার আপনি + ১ টি চুলা + ১ টি কেতলি

২

হেল্পিং হ্যান্ড রাখলেন

একই দোকানে আরও বেশি ওয়ার্কার

অনেক কাস্টমার Counter ওয়ার্কার 1, 2, 3

৩

একাধিক ব্রাঞ্চ খুললেন

আরও বেশি দোকান

অনেক কাস্টমার Map/Router স্টল A, B, C

৪

সেন্ট্রাল Warehouse

দুধ, চিনি, এসব Shared Resource দোকানগুলো একটা Warehouse থেকে নেবে

দোকান Warehouse

৫

মোবাইল ফোনে অর্ডার, দোকান থেকে পিকআপ, ডেলিভারি

আলাদা ধরনের রিকোয়েস্ট

সফটওয়্যার সিস্টেমও ঠিক এভাবেই বড় হতে থাকে। পরের সেশনগুলোতে আমরা ভিন্ন ভিন্ন টুল নিয়ে ধীরে ধীরে আলোচনা করবো। দেখবো, একেকটা টুল কীভাবে একেকটা সমস্যা সমাধানের হাতিয়ার হিসেবে কাজ করে।

০৫ রিসোর্স বাড়ালেই কেন সব ঠিক হয় না?

এটা সিস্টেম ডিজাইনের সবচেয়ে গুরুত্বপূর্ণ প্রশ্নগুলোর একটা। একটা গল্প দিয়ে শুরু করি।

আপনার একটা চুলা আছে। দশ জন ওয়ার্কার সেটা ব্যবহার করতে চায়। একসাথে শুধু একজনই ব্যবহার করতে পারে। বাকি ৯ জন ওয়েট করে।

আপনি আরো ১০ জন ওয়ার্কার হায়ার করলেন। এখন ১৯ জন ওয়ার্কার চুলার জন্য ওয়েট করছে।

চা কি ফাস্টার হলো? না। চুলাই ছিল Bottleneck, ওয়ার্কার না।

Scaling এর সবচেয়ে গুরুত্বপূর্ণ সূত্র

X বাড়ালে শুধু তখনই কাজে দেবে, যখন X-ই bottleneck। অন্য কিছু bottleneck হলে X বাড়ানো শুধুই অপচয়।

Software এ এটা হরহামেশাই ঘটে। কোনো সিস্টেম স্লো হলেই অনেক সময় আমরা নতুন Server অ্যাড করি। অথচ আসল bottleneck হয়তো Database। এক্ষেত্রে নতুন Server কোনো সমাধান নয়। কারণ সবগুলো Server-ই শেষমেশ ওই স্লো DB এর সাথেই কথা বলছে।

আগে bottleneck খুঁজুন। তারপর fix করুন। অন্ধভাবে রিসোর্স অ্যাড করবেন না।

আরেকটা বিষয় - Scaling দুইভাবে করা যায়

দোকান ছোট হলে দুটো অপশন:

Vertical scaling (ভার্টিকাল): একই জিনিস বড় করা (বড় দোকান, বড় চুলা)।
Horizontal scaling (হরাইজন্টাল): একই জিনিস বেশি করা (বেশি দোকান, বেশি চুলা)।

Software-এ:

Vertical scaling: বড়, পাওয়ারফুল সার্ভার মেশিন কেনা।
Horizontal scaling: বেশি মেশিন অ্যাড করা।

আপনারও যদি আমার মতো মনে রাখতে কষ্ট হয়, তাহলে এভাবে মনে রাখতে পারেন:

Vertical goes up (taller machine), horizontal goes wide (more machines)।

তবে পৃথিবীতে কোনো কিছুই ফ্রি না। প্রতিটারই trade-off (কিছু পাবেন, কিছু হারাবেন) আছে। Vertical স্কেলিং সিম্পল, কিন্তু একটা সিলিং হিট করে (অসীম বড় মেশিন কেনা সম্ভব না)। Horizontal স্কেলিং স্কেল করার জন্য ভালো, কিন্তু এতে কমপ্লেক্সিটি বাড়ে (অনেক মেশিন ম্যানেজ করা কঠিন)। ভাই ও বোনেরা, আপনি প্রস্তুত তো? সিস্টেম ডিজাইনের পুরো আলোচনা জুড়ে আনাচে-কানাচে ছড়িয়ে-ছিটিয়ে বিভিন্ন trade-off পড়ে থাকতে দেখবেন।

পুনরায় আরেকটা বিষয় - Single Point of Failure (SPOF)

আপনি (একমাত্র চা-মেকার) অসুস্থ হলেই পুরো দোকান বন্ধ। কোনো ব্যাকআপ নেই।

SPOF কী?

Single Point of Failure (SPOF) হলো এমন একটা component, যেটা fail করলে পুরো system ডাউন হয়ে যায়। কারণ এর কোনো backup বা alternative নেই।

এই রোগের ওষুধ? বাজারে একটাই ওষুধ পাওয়া যায়: redundancy (রিডানডেন্সি)। যা রাখবেন, একাধিক রাখবেন। একটা ডাউন হলে অন্যটা টেক ওভার করবে।

SPOF-ই System Design এর সেন্ট্রাল এনিমি। বারবার এই নাম আসবে।

০৬ “Fast” এর মানে কী?

একজন ম্যানেজার যদি বলেন “এটা fast বানাও”, এটা আসলে একটা অস্পষ্ট ইনস্ট্রাকশন। কেন?

কারণ নিচের জিনিসগুলো হাতে না থাকলে “fast” এর কোনো নির্দিষ্ট মানে দাঁড়ায় না:

একটা Numerical Value: কত millisecond?
একটা Load Condition: কেমন traffic এ?
একটা ক্লিয়ার Context: কী ধরনের application?

উদাহরণ: ২ second একটা blog এর জন্য “fast”। ১০০ millisecond একটা stock trading application এর জন্য “slow”।

Industry তে এই requirement গুলো এভাবে লেখা হয়:

SLA (Service Level Agreement): কাস্টমারকে দেওয়া প্রতিশ্রুতি। উদাহরণ: আমরা অ্যাপ্লিকেশন সার্ভারের আপটাইম ৯৯.৯% রাখবো, না হলে টাকা ফেরত। এটা একটা চুক্তি, ভাঙলে জরিমানা।
SLO (Service Level Objective): ইন্টারনাল টার্গেট। উদাহরণ: টিমের নিজস্ব টার্গেট, আপটাইম ৯৯.৯৫% রাখতেই হবে। কাস্টমার এটা জানে না, কিন্তু টিম এটা ধরেই কাজ করে।

ভাসা ভাসা Requirements থেকে একটা ব্রোকেন সিস্টেম তৈরি হয়। সবসময় Numerical Value, Load Condition, আর Context চান।

০৭ মগজে প্রেশার দিন

নিচের প্রশ্নগুলোর উত্তর আগে নিজে একটু ভাবুন। তারপর দেখুন, যেভাবে ভেবেছেন সেটা কতখানি সঠিক।

প্রশ্ন ১: ৫,০০০ কাস্টমার এলে "বেশি ওয়ার্কার হায়ার" vs "নতুন ব্রাঞ্চ খোলা", এদের মধ্যে পার্থক্য কী? কখন কোনটা ভালো?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“বেশি ওয়ার্কার নিলে ওয়ার্কলোড সহজে ম্যানেজ হয়। আর একাধিক দোকানের চেয়ে এক দোকান ম্যানেজ করা অনেক সহজ।”

এই চিন্তাকে আমি পার্শিয়াল ক্রেডিট দেবো। কিন্তু এভাবে ভাবলে একটা ক্রিটিকাল পয়েন্ট মিস হয়ে যায়:

কেন এটা ইনকমপ্লিট?

দোকান যদি হয় ২০০ sq ft এর, আর আপনি ৫০ ওয়ার্কার হায়ার করেন, তারা আসলে দাঁড়ানোর জায়গাই ঠিকমতো পাবে না। দোকান নিজেই bottleneck হয়ে যাবে, ওয়ার্কার না। একটা পয়েন্টের পর ওয়ার্কার অ্যাড করে আর কোনো লাভ নেই।

একটা এক্সট্রা ব্রাঞ্চ অ্যাড করলে দুটো এক্সট্রা বেনিফিট পাবো, যেগুলো এক দোকান কখনো দিতে পারবে না:

Distance: কাস্টমার তার নিজের কাছাকাছি ব্রাঞ্চে যায়, ফলে সার্ভিস faster হয়।
Redundancy: একটা দোকান কোনো কারণে বন্ধ হলেও অন্যটা চলবে।

সঠিক উত্তর

একই দোকানে বেশি ওয়ার্কার (vertical-ish): সিম্পল, শুরুতে খরচ বাঁচায়। কিন্তু দোকানের ফিজিক্যাল লিমিট আছে। একটা পয়েন্টের পর আর ওয়ার্কার অ্যাড করলে কোনো বেনিফিট নেই।
একাধিক ব্রাঞ্চ (horizontal-ish): ম্যানেজ করা কঠিন, কিন্তু রিসোর্স শেয়ারিং এর কোনো লিমিটেশন নেই (যেমন: এক চুলা সবার ব্যবহার করা)। প্রতিটা ব্রাঞ্চের কাছের কাস্টমার দ্রুত সার্ভিস পায়। একটা বন্ধ হলে অন্যগুলো চলতে থাকবে।

প্রশ্ন ২: Software এর বাইরে একটা রিয়াল লাইফ SPOF উদাহরণ দিন।

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে ১

“আপনি কোনো ইমার্জেন্সি কাজে ব্যস্ত থাকায় কাজটা এখন করতে পারছেন না।”

এটা ভুল কেন? “ব্যস্ত থাকা” SPOF না। SPOF মানে এমন একটা জিনিস, যেটা কাজ না করলে পুরো সিস্টেম ধসে যায়। ব্যস্ত মানে শুধু slow, কিন্তু ব্রোকেন না।

সবাই যেভাবে ভাবে ২ (আংশিক সঠিক)

“বাসা: এন্ট্রি দরজার একটাই চাবি।”

ভ্যালিড, কিন্তু একটু দুর্বল উদাহরণ। বাসা তো ঠিকই আছে, শুধু এক্সেস ভাঙা। আরো শক্তিশালী উদাহরণ হলো একটাই মেইন ডোর বা একটাই পানির লাইন, যেটা ভাঙলে বাসা একদমই আনইউজএবল।

সঠিক উদাহরণ

শহরের ইলেক্ট্রিসিটি: একটা সাবস্টেশন, পুরো এলাকা তার ওপর নির্ভরশীল। এই সমস্যা আসলে রিডানডেন্সি দিয়ে সমাধান করা হয়, একই এরিয়াতে একাধিক সাবস্টেশন রেখে।
বিয়ের শেফ টিম: কোনো কারণে টিম আসতে না পারলে অনুষ্ঠান বন্ধ। ফিক্স হলো ব্যাকআপ ক্যাটারার বা দুই টিম রাখা।
হাসপাতালের একটা ICU Ventilator: মেশিন নষ্ট হয়ে গেলে রোগী মারা যেতে পারে। সমাধান হলো ব্যাকআপ Ventilator রাখা।

প্রশ্ন ৩: Boss যদি বলেন "এটা fast বানাও", এই ইনস্ট্রাকশনটা কতটা অস্পষ্ট?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“হ্যাঁ, fast বানাই, response time কমাতে হবে।”

এই চিন্তা একটা ট্র্যাপ। এখানে “Fast” এর কোনো নির্দিষ্ট মানে নেই। তাই এই ইনস্ট্রাকশন ফলো করতে গেলে ইঞ্জিনিয়ার তার নিজের অ্যাজাম্পশনে কাজ করে, আর পরে দেখা যায় boss এর এক্সপেক্টেশন একদম আলাদা ছিল।

“Fast” এর তিনটা মিসিং পিস

একটা Numerical Value: কত millisecond?
একটা Load Condition: কেমন traffic এ?
একটা Context: কী ধরনের application, কার জন্য?

২ second এ পেজ লোড একটা ব্লগের জন্য fast। ১০০ millisecond একটা স্টক ট্রেডিং অ্যাপ্লিকেশনের জন্য slow। ভিন্ন Context এ একই নাম্বারের ভিন্ন ভিন্ন অর্থ থাকতে পারে।

সঠিক approach

Boss এর কাছে ক্লারিফিকেশন চান: “কত millisecond এ, কেমন load এ, কোন user journey?”

প্রশ্ন ৪: একটা নির্দিষ্ট পয়েন্টের পর এক্সট্রা ওয়ার্কার অ্যাড করলেও সেটা কেন আর কোনো বেনিফিট অ্যাড করে না?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“রিসোর্স ব্যবহারের একটা ম্যাক্সিমাম লিমিট আছে, তাই ম্যাক্স লিমিটে পৌঁছালে আর ওয়ার্কার বাড়িয়ে লাভ নেই।”

এই উত্তরটা ঠিক, কিন্তু আরো sharp আর specific ভাবে বলতে হবে, যাতে রিয়েল ওয়ার্ল্ডে অ্যাপ্লাই করা যায়।

সঠিক মেন্টাল মডেল

এক চুলা, ১০ ওয়ার্কার, ১ জন ব্যবহার করছে, ৯ জন ওয়েট করছে। আরো ১০ জন ওয়ার্কার অ্যাড করলে ১৯ জন ওয়েট করবে। চুলাই ছিল bottleneck, ওয়ার্কার না।

লেসন: রিসোর্সের লিমিট আছে, এই কথা শুধু মুখস্থ বললে চলবে না। কোন স্পেসিফিক রিসোর্স তার ম্যাক্স লিমিটে পৌঁছেছে, সেটা আইডেন্টিফাই করতে হবে।

Rule

X বাড়ালে শুধু তখনই কাজে দেবে, যদি X-ই bottleneck হয়। আগে bottleneck খুঁজুন।

Software এর ক্ষেত্রে কিছু উদাহরণ

Database slow হলে Web Server অ্যাড করে কোনো লাভ নেই।
Network bandwidth bottleneck হলে CPU power বাড়িয়ে লাভ নেই।
Disk slow হলে RAM বাড়িয়ে কাজ হবে না।

০৮ যে টার্মগুলো শিখলাম

টার্ম	মানে
Vertical scaling	বড়, পাওয়ারফুল মেশিন কেনা।
Horizontal scaling	আরও মেশিন অ্যাড করা।
Single Point of Failure (SPOF)	এমন একটা component, যেটা fail করলে পুরো system ডাউন হয়ে যায়।
Redundancy	একই জিনিসের আরেকটা অল্টারনেটিভ রাখা, যাতে একটা fail করলে অন্যটা সেই রেসপন্সিবিলিটি নিতে পারে।
Bottleneck	System এর সবচেয়ে slow part, যেটা পুরো সিস্টেমের গতি আটকে রাখে।
SLO / SLA	কোনো সার্ভিসের মেজারেবল টার্গেট / টার্গেট না মানলে কী হবে।

০৯ শর্ট সামারি

System Design দরকার হয়, কারণ যা ১০ user এর জন্য কাজ করে, সেটাই ১০ মিলিয়ন user এর জন্য ভেঙে পড়ে। ঠিক একটা চা দোকান বড় হওয়ার মতোই।
System Design এর মূল প্রশ্ন সবসময় একই: load বাড়লেও কীভাবে fast, reliable, আর correct থাকবো।
প্রতিটা fancy concept (load balancer, cache, microservice) আসলে চা দোকানের একেকটা সমস্যা সমাধানের tool।

১০ মনে রাখুন

আগে bottleneck খুঁজুন। অন্ধভাবে রিসোর্স অ্যাড করবেন না।
Redundancy SPOF সরায়। সবসময় প্রশ্ন করুন: “এটা ফেইল করলে কী হবে?”
“Fast” এর জন্য numerical value, load, আর context লাগে। Vague requirement কখনো accept করবেন না।
Vertical = taller machine. Horizontal = more machines. প্রতিটার trade-off আছে।