ধরা যাক, তুমি একটি ছোট্ট চায়ের দোকান খুলেছ। প্রথমে, কাস্টমার বেশি নেই, তাই তুমি একাই সব কাজ করছ—চা বানানো, কাস্টমারের অর্ডার নেয়া, টাকা নেয়া, সবকিছু। এভাবে দোকান চালানো সহজ, কারণ কাস্টমার কম এবং কাজের চাপও কম।
কিন্তু কিছুদিন পর দোকানের সুনাম ছড়িয়ে পড়ে, আর কাস্টমারের সংখ্যা বাড়তে থাকে। এবার তুমি একা সব সামলাতে হিমশিম খেতে শুরু করলে। এখন তোমার প্রয়োজন হবে কিছু লোককে কাজে লাগানো এবং কাজগুলোকে ভাগ করে দেয়া।
এবার আসি সিস্টেম ডিজাইন এর দিকে:
১. মডিউলারিটি (Modularity)
ধরা যাক, তোমার চায়ের দোকানে আলাদা আলাদা স্টেশন আছে—একটি স্টেশনে চা বানানো হয়, আরেকটিতে অর্ডার নেয়া হয়, এবং আরেকটিতে টাকা নেয়া হয়।
এখানে প্রতিটি কাজ আলাদা মডিউল হিসেবে কাজ করছে। এটাই মডিউলারিটি—যখন সিস্টেমকে ছোট ছোট অংশে ভাগ করে প্রতিটি অংশের নির্দিষ্ট কাজ দেয়া হয়। এতে একটি মডিউলে কোনো সমস্যা হলে, পুরো সিস্টেমে প্রভাব পড়ে না।
২. স্কেলেবিলিটি (Scalability)
ধরা যাক, তোমার দোকানের জনপ্রিয়তা এত বেড়ে গেছে যে, একই ধরনের আরেকটি দোকান খুলতে হবে। তুমি যদি প্রথম দোকানের মতোই একই নিয়মে নতুন দোকান সাজাও, তাহলে সেটাও সহজে চালানো যাবে।
এটা হচ্ছে স্কেলেবিলিটি, যেখানে সিস্টেমকে এমনভাবে ডিজাইন করা হয় যাতে লোড বা কাজের চাপ বেড়ে গেলেও সিস্টেম কার্যকর থাকে।
৩. লোড ব্যালান্সিং (Load Balancing)
তুমি দেখলে যে, সব কাস্টমার একসাথে লাল চা অর্ডার করছে, আর দুধ চা বানানোর লোকটির কাজ তেমন নেই। তখন তুমি সিদ্ধান্ত নিলে, দুইজন চা বানানোর লোক রাখবে এবং যেই কাজ বেশি আসবে সেটাকে সমানভাবে ভাগ করে দেবে।
এটা হচ্ছে লোড ব্যালান্সিং, যেখানে কাজের চাপ সিস্টেমের বিভিন্ন অংশে সমানভাবে ভাগ করে দেয়া হয়।
৪. ক্যাশিং (Caching)
ধরা যাক, প্রতিদিন সকাল ১০টায় কাস্টমারের ভিড় হয়, আর সবাই লাল চা চায়। তুমি আগে থেকেই কিছু লাল চা বানিয়ে রাখলে যাতে কাস্টমার আসার সঙ্গে সঙ্গেই তাদের চা দিতে পারো।
এটা হচ্ছে ক্যাশিং। সিস্টেম ডিজাইনে, বারবার একই ডেটা প্রসেস না করে কিছু ডেটা আগে থেকেই সংরক্ষণ করে রাখা হয় যাতে দ্রুত কাজ করা যায়।
৫. ফল্ট টলারেন্স (Fault Tolerance)
তোমার দোকানের গ্যাস চুলা যদি হঠাৎ খারাপ হয়ে যায়, তখন চা বানানো বন্ধ হয়ে যাবে। কিন্তু যদি একটি অতিরিক্ত চুলা আগে থেকেই রাখা থাকে, তাহলে চা বানানো চালিয়ে যাওয়া সম্ভব হবে।
এটি ফল্ট টলারেন্স—সিস্টেমকে এমনভাবে ডিজাইন করা যাতে কোনো একটি অংশ ব্যর্থ হলেও সিস্টেম চালু থাকে।
৬. ডাটাবেস শার্ডিং (Database Sharding)
তোমার দোকানে এত বেশি কাস্টমার আসে যে, সবার অর্ডারের হিসাব রাখতে দুটি আলাদা খাতা ব্যবহার শুরু করলে—একটি পুরোনো কাস্টমারের জন্য, আরেকটি নতুন কাস্টমারের জন্য।
এটাই ডাটাবেস শার্ডিং, যেখানে ডেটাবেসকে ছোট ছোট অংশে ভাগ করে রাখা হয় যাতে তা দ্রুত এবং কার্যকরভাবে কাজ করতে পারে।
৭. সিংগল পয়েন্ট অফ ফেলিওর (Single Point of Failure)
ধরা যাক, তোমার দোকানে শুধুমাত্র একটি চা বানানোর লোক আছে। যদি সে অসুস্থ হয়ে যায়, তাহলে পুরো দোকানের কার্যক্রম বন্ধ হয়ে যাবে।
এটা সিংগল পয়েন্ট অফ ফেলিওর, যেখানে সিস্টেমে এমন কোনো অংশ থাকে যা ব্যর্থ হলে পুরো সিস্টেম বন্ধ হয়ে যায়। ভালো সিস্টেম ডিজাইনে, এই ঝুঁকিকে কমানোর জন্য বিকল্প ব্যবস্থা রাখা হয়।
৮. কনসিসটেন্সি (Consistency), অ্যাভেলেবিলিটি (Availability), পার্টিশন টলারেন্স (Partition Tolerance) – CAP থিওরেম
তুমি চাও, কাস্টমাররা সবসময় চা পেয়ে যাক (অ্যাভেলেবিলিটি), এবং যদি তারা কোনো বিশেষ ধরনের চা চায়, তা যেন সঠিকভাবে তৈরি হয় (কনসিসটেন্সি)। তবে, যদি কোনো কারণে এক দোকান বন্ধ হয়ে যায়, তখন অন্য দোকান থেকেও যেন চা দেয়া যায় (পার্টিশন টলারেন্স)। কিন্তু সব তিনটি বিষয় একসাথে পুরোপুরি নিশ্চিত করা সবসময় সম্ভব নয়।
CAP থিওরেম অনুযায়ী, একসাথে এই তিনটি বিষয় সিস্টেমে রাখা খুব কঠিন, তাই কোনো একটি বা দুটি বিষয়কে বেশি গুরুত্ব দেয়া হয়।
এই উদাহরণগুলো তোমার চায়ের দোকানের মাধ্যমে সিস্টেম ডিজাইনের মূল নীতিগুলো এবং টার্মগুলো সহজে বোঝার চেষ্টা করেছে। বাস্তব জীবনের সমস্যা সমাধানের জন্য, এই ধরনের সিস্টেম ডিজাইনের নীতিমালা এবং কৌশলগুলি অত্যন্ত গুরুত্বপূর্ণ।