Microservices Architecture Vs Monolith

মাইক্রোসার্ভিস (Microservices) আর্কিটেকচারকে আমরা একটি "বড় রেস্টুরেন্ট পরিচালনা"-র সাথে তুলনা করে ধাপে ধাপে বুঝতে পারি।

১. Monolith vs. Microservices (একাই ১০০ বনাম আলাদা টিম)

• Monolithic (পুরানো পদ্ধতি): ধরুন, আপনার একটি রেস্টুরেন্ট আছে যেখানে একজন রাঁধুনিই সব কাজ করেন। তিনিই বার্গার বানান, তিনিই পিৎজা বানান, আবার তিনিই ক্যাশ কাউন্টারে টাকা নেন।

  • সমস্যা: কোনো কারণে ওই রাঁধুনি অসুস্থ হলে আপনার পুরো রেস্টুরেন্ট বন্ধ হয়ে যাবে।

• Microservices (আধুনিক পদ্ধতি): এখন আপনি পদ্ধতি বদলালেন। আপনি কাজের জন্য আলাদা আলাদা ছোট টিম বা স্টল বসালেন।

  • একজন শুধু বার্গার বানাবে।

  • একজন শুধু পিৎজা বানাবে।

  • একজন শুধু পেমেন্ট বা টাকা নেবে।

  • সুবিধা: যদি পিৎজা ওয়ালা অসুস্থ হয়ে না আসে, তবুও আপনার বার্গার বিক্রি কিন্তু বন্ধ হবে না। ব্যবসা চলতে থাকবে।

২. Database per Service (সবার নিজস্ব আলাদা খাতা)

• আগে: রেস্টুরেন্টের সব হিসাব-নিকাশ একটা মাত্র বড় খাতায় (Database) লেখা হতো। সবাই ওই এক খাতায় লিখত বলে অনেক সময় কাটাকাটি বা ভুল হতো।

• এখন (Microservices): আপনি নিয়ম করে দিলেন—

  • বার্গার ওয়ালার নিজের আলাদা খাতা থাকবে।

  • পেমেন্ট ওয়ালার নিজের আলাদা খাতা থাকবে।

  • নিয়ম: কেউ কারো খাতায় হাত দিতে পারবে না। যদি বার্গার ওয়ালার কোনো তথ্যের দরকার হয়, সে পেমেন্ট ওয়ালাকে মুখে জিজ্ঞেস করবে (API Call), কিন্তু সরাসরি খাতায় হাত দেবে না।

৩. Communication (একে অপরের সাথে কথা বলা)

এই আলাদা আলাদা টিমগুলো নিজেদের মধ্যে কীভাবে যোগাযোগ করবে? আপনি দুটি উপায় ঠিক করে দিতে পারেন:

1. Sync (ফোনে কথা বলা - REST API, gRPC): ধরুন, অর্ডার কাউন্টার থেকে পিৎজা ওয়ালাকে ফোন দেওয়া হলো, "ভাই, একটা পিৎজা দিন।" যতক্ষণ পিৎজা ওয়ালা কনফার্ম না করছে, ততক্ষণ কাউন্টারের লোক ফোন কানে ধরে অপেক্ষা করবেন। 

2. Async (মেসেজ পাঠানো - Message Broker/RabbitMQ): কাউন্টারের লোক একটি চিরকুটে অর্ডার লিখে বক্সে ফেলে দিলেন। পিৎজা ওয়ালা যখন ফ্রি হবেন, তখন চিরকুট দেখে পিৎজা বানিয়ে দেবেন। এতে কাউন্টারের লোকের সময় নষ্ট হলো না।

৪. API Gateway (রিসেপশনিস্ট বা ম্যানেজার)

যখন কোনো কাস্টমার (User) আপনার রেস্টুরেন্টে আসবে, সে কি একবার পিৎজা ওয়ালার কাছে দৌড়াবে, আবার ড্রিংকস ওয়ালার কাছে দৌড়াবে? নিশ্চয়ই না।

• আপনি গেটে একজন ম্যানেজার বা রিসেপশনিস্ট (API Gateway) বসিয়ে দিলেন।

• কাস্টমার শুধু ম্যানেজারকে বলবে: "আমার পিৎজা আর ড্রিঙ্কস  লাগবে।"

• ম্যানেজার দৌড়ে গিয়ে পিৎজা আর ড্রিঙ্কস  এনে কাস্টমারকে দেবেন।

• কাজ: কাস্টমারকে ভেতরের ঝামেলা বুঝতে না দেওয়া এবং সিকিউরিটি চেক করা।

৫. Service Discovery (ঠিকানা খুঁজে বের করা)

আপনার রেস্টুরেন্টটি অনেক বড়। কে কোন টেবিলে বসে কাজ করছে, তা মনে রাখা কঠিন।

• তাই আপনার কাছে একটি "ডিরেক্টরি বা ফোনবুক" (Service Registry) থাকে।

• যখন পেমেন্ট ডিপার্টমেন্টের দরকার হয়, তখন এই ফোনবুকে দেখা হয় পেমেন্ট ওয়ালা এখন কোন ডেস্কে (IP Address) বসে আছেন।

৬. Fault Tolerance / Circuit Breaker (ফিউজ বক্স)

ধরুন, হঠাৎ পিৎজা ওভেনে আগুন লেগে গেছে বা সেটি নষ্ট হয়ে গেছে (Service Crash)।

• এখন ম্যানেজার যদি বারবার ওই নষ্ট ওভেনের দিকেই যেতে থাকেন, তাহলে সময় নষ্ট হবে এবং কাস্টমার রেগে যাবেন।

• Circuit Breaker হলো ইলেকট্রিক ফিউজের মতো। সে যখন দেখবে পিৎজা সেকশনে সমস্যা, সে তৎক্ষণাৎ কাস্টমারকে জানিয়ে দেবে, "স্যার, পিৎজা এখন হবে না, আপনি বার্গার নিতে পারেন।"

• এতে আপনার পুরো সিস্টেমটি অচল হয়ে যাবে না, আংশিক চালু থাকবে।