System Design কী, কীভাবে ভাববে

বাসায় ৫ জনের জন্য রান্না করা আর বিয়েবাড়িতে ৫০০ জনের জন্য রান্না করা, দুটোই "রান্না"। কিন্তু দ্বিতীয়টায় একজন বাবুর্চি দিয়ে হয় না। লাগে অনেক বাবুর্চি, আগে থেকে কেটে রাখা সবজি, খাবার পরিবেশনের লাইন, আর একজন দেখার লোক যে ঠিক করে কে কোন টেবিলে খাবার দেবে। আর কোনো চুলা নষ্ট হলে বিকল্প চুলাও লাগে।

Software এও ঠিক তাই। ১০ জন user এর app একটা ছোট server এ চলে যায়। ১০ লাখ user হলে কীভাবে সব অংশ সাজাবে, সেই পরিকল্পনার নামই System Design।

#System Design আসলে কী

System design মানে হলো এই প্রশ্নগুলোর উত্তর ঠিক করা:

• System টা কোন কোন অংশ (component) দিয়ে তৈরি হবে? যেমন app server, database, cache, queue।
• অংশগুলো একে অপরের সাথে কীভাবে কথা বলবে? যেমন HTTP API, message queue।
• Data কোথায় থাকবে, কীভাবে থাকবে?
• User বাড়লে কী হবে? কোনো অংশ নষ্ট হলে কী হবে?
• এসব করতে খরচ কত?

Flutter developer হিসেবে তুমি আসলে ছোট পরিসরে এটা করেই ফেলেছো। কোন data local এ cache করবে, কোন state কোথায় রাখবে, API fail করলে কী দেখাবে, এগুলো client-side system design। এখন সেই চিন্তাটা পুরো system এ, server সহ, করতে শিখবো।

#দুই ধরনের requirement

যেকোনো design শুরু হয় requirement দিয়ে। Requirement দুই রকম।

Functional requirement: system কী করবে। Foodpanda ধরনের app এর জন্য:

• User restaurant খুঁজতে পারবে
• Order দিতে পারবে, টাকা দিতে পারবে
• Rider এর অবস্থান live দেখতে পারবে

Non-functional requirement: system কেমনভাবে করবে। একই app এর জন্য:

• Restaurant list ২০০ ms এর মধ্যে আসবে
• দিনে ১০ লাখ order সামলাবে
• বছরে ৯ ঘণ্টার বেশি বন্ধ থাকবে না
• Payment এ একটা টাকাও হারাবে না বা দুইবার কাটবে না

Interview আর বাস্তব কাজ, দুই জায়গাতেই মানুষ functional requirement নিয়ে বেশি ভাবে। কিন্তু design কেমন হবে সেটা ঠিক করে non-functional requirement। "দিনে ১০০ order" আর "দিনে ১০ লাখ order" এর design একদম আলাদা।

#যে গুণগুলো বারবার আসবে

পুরো course জুড়ে এই শব্দগুলো বারবার দেখবে। এখন শুধু পরিচয়, পরে প্রতিটার আলাদা অধ্যায় আছে।

#Trade-off: সব একসাথে পাওয়া যায় না

System design এর সবচেয়ে গুরুত্বপূর্ণ কথা: perfect design বলে কিছু নেই, আছে trade-off। একটা জিনিস ভালো করতে গেলে আরেকটায় ছাড় দিতে হয়।

• Consistency বনাম Availability: Network ভাগ হয়ে গেলে হয় পুরনো data দেখিয়ে চালু থাকবে, নয়তো বন্ধ থাকবে যতক্ষণ সঠিক data নিশ্চিত না হয়। bKash এর balance এর ক্ষেত্রে সঠিকতা জরুরি, Facebook এর like count এ কয়েক সেকেন্ড পুরনো সংখ্যা চলে। (CAP অধ্যায়)
• Latency বনাম খরচ: সব data RAM এ (cache) রাখলে খুব দ্রুত, কিন্তু RAM দামি।
• সরলতা বনাম flexibility: Microservice এ আলাদা আলাদা team আলাদা কাজ করতে পারে, কিন্তু system অনেক জটিল হয়ে যায়।
• নতুন data বনাম গতি: Cache থেকে দিলে দ্রুত, কিন্তু data কিছুটা পুরনো হতে পারে।

ভালো engineer আর সাধারণ engineer এর পার্থক্য এখানেই: ভালো engineer বলতে পারে "আমি X বেছে নিয়েছি, কারণ এই system এ Y বেশি জরুরি, আর এর দাম হিসেবে Z মেনে নিচ্ছি।"

#Design করার ৬টা ধাপ

যেকোনো system design করতে (interview হোক বা অফিসের আসল কাজ) এই ধাপগুলো ধরে চলো। এই site এর সব case study এই ধাপেই সাজানো।

1. Requirement: কী কী feature লাগবে (functional), আর কতটা দ্রুত, কতটা নির্ভরযোগ্য (non-functional)। কী বানাবো না, সেটাও ঠিক করো।
2. Estimation: দিনে কত user, প্রতি সেকেন্ডে কত request, কত storage। এটা থেকে বোঝা যায় একটা server যথেষ্ট নাকি ১০০টা লাগবে। (হিসাবের অধ্যায়)
3. API: Client আর server কী কী endpoint দিয়ে কথা বলবে। যেমন POST /orders, GET /restaurants?lat=..&lng=..
4. Data model: কোন কোন table বা collection, কোন field, কোন database (SQL নাকি NoSQL)।
5. High-level design: বড় বড় box আঁকো: client, load balancer, service, database, cache, queue। Data কোন পথে চলবে দেখাও।
6. Deep dive: সবচেয়ে কঠিন বা দুর্বল জায়গাগুলো নিয়ে গভীরে যাও। কোথায় bottleneck, কোনটা নষ্ট হলে কী হবে, কীভাবে scale করবে।

#একটা system কীভাবে বড় হয়

কোনো বড় system প্রথম দিনেই বড় ছিল না। প্রায় সব system এভাবে ধাপে ধাপে বড় হয়:

প্রতিটা ধাপে নতুন একটা সমস্যা আসে, আর সেটার সমাধান হিসেবে নতুন একটা অংশ যোগ হয়:

• একটা server এ আর কুলাচ্ছে না → database আলাদা machine এ সরাও
• App server এ চাপ বেশি → একাধিক app server, সামনে load balancer
• Database এ একই query বারবার → cache
• Database এ read অনেক বেশি → read replica
• ছবি আর video ধীরে আসছে → CDN
• কিছু কাজ অনেক সময় নেয় (email, report) → message queue
• একটা database এ data আর ধরছে না → sharding

এই course এর System Design line টা ঠিক এই ক্রমেই সাজানো।

#System Design কীভাবে শিখবে

• ছবি আঁকো। প্রতিটা অধ্যায়ের diagram খাতায় নিজে আঁকো, বই না দেখে।
• "কেন" জিজ্ঞেস করো। "Cache লাগে" মুখস্থ না করে বোঝো "কেন লাগে, না দিলে কী হতো, দিলে কী নতুন সমস্যা আসে"।
• নিজের project এ লাগাও। Python line এ তুমি যা বানাবে (Redis cache, Celery queue, WebSocket), সেগুলো এখানের তত্ত্বের হাতে-কলমে রূপ।
• আসল company এর engineering blog পড়ো। Netflix, Uber, Discord, Shopify এর blog এ তারা বাস্তব সমস্যা আর সমাধান লেখে।

#অনুশীলন

#নিজেকে যাচাই করো

Functional আর non-functional requirement এর পার্থক্য কী? একটা করে উদাহরণ দাও।

Functional হলো system কী করবে, যেমন "user ছবি upload করতে পারবে"। Non-functional হলো কেমনভাবে করবে, যেমন "১০ MB ছবি ৫ সেকেন্ডের মধ্যে upload হবে" বা "system 99.9% সময় চালু থাকবে"।

"এই design সবচেয়ে ভালো" কথাটা কেন প্রায় সবসময় ভুল?

কারণ প্রতিটা design কিছু একটা ভালো করে আরেকটায় ছাড় দেয় (trade-off)। কোন design ভালো সেটা নির্ভর করে requirement এর উপর। ঠিক কথা হলো "এই requirement এর জন্য এই design ভালো, কারণ ..."।

Latency আর throughput এর পার্থক্য রাস্তার উদাহরণ ছাড়া অন্য উদাহরণে বলো।

একটা ব্যাংকের কাউন্টার: একজন গ্রাহকের কাজ হতে কত মিনিট লাগে সেটা latency। ঘণ্টায় কতজন গ্রাহকের কাজ হয় সেটা throughput। কাউন্টার বাড়ালে throughput বাড়ে, কিন্তু প্রতিজনের সময় একই থাকে।

Design এর ৬টা ধাপ ক্রমানুসারে বলো।

Requirement, Estimation, API, Data model, High-level design, Deep dive।