Architectural Patterns (আর্কিটেকচারাল প্যাটার্নস)
সফটওয়্যার আর্কিটেকচার হলো একটি সিস্টেমের কঙ্কাল বা ব্লু-প্রিন্ট। ইন্টারভিউতে বিভিন্ন আর্কিটেকচারাল স্টাইল এবং কখন কোনটি ব্যবহার করতে হবে, তা নিয়ে বিস্তারিত আলোচনা করা হয়।
১. প্রধান ৯টি আর্কিটেকচারাল প্যাটার্ন (Overview)
সচরাচর ব্যবহৃত প্রধান ৯টি প্যাটার্ন হলো: ১. Layered Pattern: কোডকে বিভিন্ন লেয়ারে (উদা: Presentation, Business, Data) ভাগ করা। ২. Client-Server: ক্লায়েন্ট রিকোয়েস্ট পাঠায় এবং সার্ভার রেসপন্স দেয়। ৩. Master-Slave: একজন লিডার (Master) কাজ ভাগ করে দেয় এবং ফলোয়াররা (Slaves) তা পালন করে। ৪. Pipe-Filter: ডেটার একটি স্ট্রিম বিভিন্ন ফিল্টারের মাধ্যমে প্রসেস হয়। ৫. Broker Pattern: বিভিন্ন কম্পোনেন্টের মধ্যে সমন্বয় করার জন্য একটি ব্রোকার থাকে। ৬. Peer-to-Peer: প্রতিটি নোড একই সাথে ক্লায়েন্ট এবং সার্ভার হিসেবে কাজ করে। ৭. Event-Bus: ইভেন্টের মাধ্যমে বিভিন্ন কম্পোনেন্ট একে অপরের সাথে যোগাযোগ করে। ৮. Model-View-Controller (MVC): অ্যাপ্লিকেশন লজিক এবং ইউআই আলাদা রাখা। ৯. Blackboard Pattern: একটি কমন নলেজ বেস ব্যবহার করে জটিল সমস্যা সমাধান করা।
২. ক্লায়েন্ট-সার্ভার আর্কিটেকচার (Client-Server)
এটি ইন্টারনেটের সবচেয়ে কমন আর্কিটেকচার।
- কিভাবে কাজ করে: ইউজার (Client) একটি রিকোয়েস্ট পাঠায় এবং সার্ভার তা প্রসেস করে ডেটা ফেরত দেয়।
- সুবিধা: সেন্ট্রালাইজড কন্ট্রোল এবং সিকিউরিটি।
- সীমাবদ্ধতা: সার্ভার ডাউন হলে পুরো সিস্টেম অফ হয়ে যায় (SPOF)।
৩. সার্ভারলেস আর্কিটেকচার (Serverless Architecture)
এখানে ডেভেলপারকে সার্ভার ম্যানেজ করতে হয় না। ক্লাউড প্রোভাইডার (উদা: AWS Lambda) অটোমেটিক্যালি কোড রান করার জন্য সার্ভার অ্যালোকেট করে।
- সুবিধা: শুধুমাত্র ব্যবহারের ওপর ভিত্তি করে খরচ (Pay-as-you-go), অসীম স্কেলেবিলিটি।
- সীমাবদ্ধতা: 'Cold Start' সমস্যা এবং ভেন্ডর লক-ইন।
৪. ইভেন্ট-ড্রিভেন আর্কিটেকচার (Event-Driven)
এই পদ্ধতিতে সিস্টেমের কম্পোনেন্টগুলো সরাসরি একে অপরকে কল না করে 'Events' এর মাধ্যমে কথা বলে।
- কিভাবে কাজ করে: একটি সার্ভিস কোনো কাজ শেষ করে একটি ইভেন্ট পাবলিশ করে, অন্য সার্ভিসগুলো তা শুনে (Listen) কাজ শুরু করে।
- সুবিধা: হাইলি ডিকপলড (Decoupled) এবং স্কেলেবল।
- উদা: অর্ডার দিলে সাথে সাথে ইমেইল পাঠানো এবং ইনভেন্টরি আপডেট করা।
৫. পিয়ার-টু-পিয়ার (P2P) আর্কিটেকচার
এখানে কোনো সেন্ট্রাল সার্ভার থাকে না। প্রতিটি নোড (Peer) সমান ক্ষমতার অধিকারী।
- সুবিধা: কোনো সিঙ্গেল পয়েন্ট অফ ফেইলিওর নেই, নেটওয়ার্ক যত বড় হয় তত শক্তিশালী হয়।
- উদা: BitTorrent, Blockchain.
৬. সাধারণ ইন্টারভিউ প্রশ্নোত্তর (General Q&A)
প্রশ্ন ১: কখন আপনি মনোলিথ থেকে মাইক্রোসার্ভিসে মুভ করবেন?উত্তর: যখন আপনার টিম অনেক বড় হয়ে যাবে এবং আলাদা আলাদা ফিচারের জন্য আলাদা স্কেলিং প্রয়োজন হবে। যদি মনোলিথ মেইনটেইন করা দুঃসাধ্য হয়ে পড়ে, তখনই মাইক্রোসার্ভিসে যাওয়া উচিত।
প্রশ্ন ২: 'Cold Start' কী?উত্তর: সার্ভারলেস ফাংশন (উদা: AWS Lambda) যদি অনেকক্ষণ ব্যবহৃত না হয়, তবে প্রথমবার কল করার সময় ক্লাউড প্রোভাইডারকে নতুন করে কন্টেইনার সেটআপ করতে হয়। এতে শুরুতে কিছু মিলি-সেকেন্ড দেরি হয়, একেই কোল্ড স্টার্ট বলে।
প্রশ্ন ৩: ইভেন্ট-ড্রিভেন সিস্টেমে 'Idempotency' কেন রিচুয়াল?উত্তর: কারণ নেটওয়ার্ক সমস্যার কারণে একই ইভেন্ট দুইবার ডেলিভার হতে পারে। সিস্টেম যেন একই কাজ দুইবার না করে, সেজন্য ইভেন্ট আইডি দিয়ে চেক করা জরুরি।
৭. সিনারিও ভিত্তিক প্রশ্ন (Scenario-based Questions)
সিনারিও ১: "আপনি এমন একটি ভিডিও স্ট্রিমিং সাইট বানাচ্ছেন যেখানে কোটি কোটি মানুষ একসাথে খেলা দেখে। আপনি কোন আর্কিটেকচার ফলো করবেন?"
সমাধান: এখানে Client-Server এর সাথে CDN (Edge Computing) এবং সম্ভবত কিছু অংশে P2P (Peer-assisted streaming) ব্যবহার করা যেতে পারে ব্যান্ডউইথ খরচ কমাতে। ডিস্ট্রিবিউটেড রিড রেপ্লিকা ব্যবহার করাও জরুরি।
সিনারিও ২: "আপনার বাজেট অত্যন্ত কম এবং ট্রাফিক সারাদিন সমান থাকে না, মাঝে মাঝে হঠাৎ স্পাইক আসে। কোন আর্কিটেকচার সেরা?"
সমাধান: এখানে Serverless Architecture সেরা হবে। কারণ ট্রাফিক না থাকলে কোনো খরচ হবে না, আবার স্পাইক আসলে এটি অটোমেটিক্যালি স্কেল হবে।
সিনারিও ৩: "একটি চ্যাটিং অ্যাপের জন্য ইভেন্ট-ড্রিভেন আর্কিটেকচার কেন ভালো?"
সমাধান: কারণ ইউজারের মেসেজগুলো একেকটি ইভেন্ট। এই ইভেন্টগুলো সাবস্ক্রাইবারদের (অন্যান্য ইউজার) কাছে সাথে সাথে পুশ করার জন্য ইভেন্ট-ড্রিভেন মেকানিজম এবং ওয়েব-সকেট অত্যন্ত কার্যকর।
TIP
আর্কিটেকচার নির্বাচনের সময় সবসময় YAGNI (You Ain't Gonna Need It) মনে রাখবেন। শুরুতেই ওভার-ইঞ্জিনিয়ারিং না করে সিম্পল কিছু দিয়ে শুরু করা ভালো।