Monolith vs Microservices

সমস্যাটা কী?

তুমি একটা বড় application বানাচ্ছ — ধরো একটা e-commerce platform। এতে আছে user account, product catalog, cart, payment, shipping, notification — অনেক আলাদা feature।

এই সব feature কীভাবে সাজাবে?

1. সব এক জায়গায়, এক code base, এক deployable unit — একসাথে build, একসাথে deploy। এটাই Monolith।
2. প্রতিটা feature আলাদা ছোট service — user service, payment service, shipping service; প্রত্যেকে নিজে deploy ও scale হয়। এটাই Microservices।

এই সিদ্ধান্ত শুধু code নয়, পুরো দল-গঠন, deploy পদ্ধতি ও খরচ বদলে দেয়। তাই trade-off ভালো করে বোঝা দরকার।

প্রথমটা: Monolith

Monolith মানে পুরো application একটাই Deployable Unit — সব feature-এর code এক জায়গায়, একসাথে build হয়, একসাথে চলে এক process-এ, একটাই database-এ সাধারণত।

সুবিধা:

• সহজ শুরু। এক project, এক code base — নতুন ডেভেলপার দ্রুত বুঝে কাজ শুরু করতে পারে।
• সহজ deploy। একটা জিনিস build করে deploy করলেই হলো।
• সহজ debugging ও testing। সব এক জায়গায়, এক function আরেকটাকে সরাসরি call করে — কোনো network নেই।
• দ্রুত development শুরুর দিকে — কম যন্ত্রপাতি, কম জটিলতা।

অসুবিধা:

• বড় হলে ভারী হয়। code base বিশাল হলে বোঝা, build ও deploy ধীর হয়।
• পুরোটা একসাথে scale করতে হয় — শুধু payment-এ চাপ বাড়লেও পুরো app-কে scale করতে হয়।
• একটা bug পুরো app ফেলে দিতে পারে। এক feature crash করলে সব বন্ধ।
• বড় দলে অনেকে একই code-এ একসাথে কাজ করলে পরস্পরের পথে এসে দাঁড়ায়।

দ্বিতীয়টা: Microservices

Microservices মানে application-কে অনেক ছোট, স্বাধীন service-এ ভাগ করা — প্রতিটা একটা নির্দিষ্ট কাজ করে (user, payment, shipping)। প্রত্যেকের নিজের code base, প্রায়ই নিজের database, এবং প্রত্যেকে আলাদাভাবে deploy ও scale হয়। এরা পরস্পরের সাথে network (API/message) দিয়ে কথা বলে — অর্থাৎ এটি একটা Distributed System।

কোন কাজ কোন service-এ থাকবে, সেই সীমারেখাকে বলে Service Boundary — এটা ঠিকভাবে টানা microservices-এর সবচেয়ে কঠিন ও গুরুত্বপূর্ণ অংশ।

সুবিধা:

• স্বাধীন deploy। payment service আপডেট করতে পুরো app নয়, শুধু সেটাই deploy করো।
• আলাদা scaling। শুধু যে service-এ চাপ, সেটাই বেশি বানাও — সাশ্রয়ী।
• দলগত স্বাধীনতা। আলাদা দল আলাদা service-এ নিজের গতিতে কাজ করে।
• আংশিক fault isolation। একটা service পড়ে গেলে পুরো app না-ও পড়তে পারে।

অসুবিধা:

• Distributed জটিলতা। service-রা network দিয়ে কথা বলে — তাই network failure, latency, retry সামলাতে হয়।
• Monitoring ও debugging কঠিন — একটা request অনেক service ঘুরে যায়।
• Data consistency কঠিন — আলাদা database-এ data মিলিয়ে রাখা জটিল।
• বাড়তি অবকাঠামো (deployment, service discovery) — খরচ ও পরিশ্রম বেশি।

পাশাপাশি তুলনা

কখন কোনটা বেছে নেবে

• Monolith দিয়ে শুরু করো — ছোট দল, নতুন product, যখন দ্রুত বাজারে আসা জরুরি আর scale এখনও বড় নয়। বেশিরভাগ startup-এর জন্য এটাই সঠিক শুরু।
• Microservices-এ যাও যখন — দল বড় ও একাধিক, কিছু অংশ আলাদাভাবে scale করা দরকার, এবং distributed system সামলানোর প্রকৌশলগত পরিপক্বতা আছে।
• জনপ্রিয় ব্যবহারিক পথ: monolith দিয়ে শুরু, ব্যথা বুঝে ধীরে ধীরে নির্দিষ্ট অংশ আলাদা service-এ বের করা।

বাস্তব উদাহরণ

• Amazon ও Netflix শুরু করেছিল monolith দিয়ে, পরে scale ও দল বড় হওয়ায় microservices-এ গেছে — এখন Netflix-এর শত শত service।
• Shopify ইচ্ছাকৃতভাবে একটা সুসংগঠিত বড় monolith (modular monolith) বজায় রেখেছে এবং বিশাল scale সামলায় — প্রমাণ যে microservices-ই একমাত্র পথ নয়।
• Uber দ্রুত বৃদ্ধির সময় বহু microservice বানিয়েছিল, পরে অতিরিক্ত খণ্ডিতকরণের জটিলতা টের পেয়ে কিছু অংশ একত্র করার দিকে গেছে — অর্থাৎ ভারসাম্যই আসল।