Microservices Architecture

সমস্যাটা কী?

একটা ই-কমার্স অ্যাপ ভাবো — Daraz-এর মতো। শুরুতে এক টিম একটাই বড় কোডবেইজে সব লিখল: user, product, cart, payment, order, notification — সবকিছু একসাথে। একে বলে Monolith। প্রথম দিকে দারুণ চলে।

কিন্তু কোম্পানি বড় হলে সমস্যা শুরু হয়। শুধু payment-এর একটা ছোট বাগ ঠিক করতে গেলেও পুরো অ্যাপটা আবার deploy করতে হয়। একটা টিমের পরিবর্তন আরেকটা টিমের কাজ ভেঙে দেয়। কোডবেইজ এত বড় যে নতুন কেউ ঢুকে কিছু বোঝে না। আর payment-এ চাপ বাড়লে শুধু payment scale করা যায় না — পুরো অ্যাপটাই scale করতে হয়, যেটা ব্যয়বহুল।

এই যন্ত্রণা থেকেই Microservices জন্ম নেয়।

মূল ধারণা

Microservices architecture হলো এমন একটা পদ্ধতি যেখানে একটা বড় অ্যাপকে অনেকগুলো ছোট, স্বাধীনভাবে deploy-যোগ্য সেবায় (service) ভাগ করা হয়। প্রতিটি Microservice একটা নির্দিষ্ট business ক্ষমতার (যেমন payment) মালিক এবং তার নিজস্ব data রাখে।

মূল দর্শন হলো: একটা বড় টিমকে অনেক ছোট টিমে ভাগ করো, প্রতিটি টিমকে একটা সেবা দাও, আর তাদের নিজেদের গতিতে কাজ করতে দাও।

প্রতিটি সেবা একটা Bounded Context ঘিরে গড়া — অর্থাৎ একটা স্পষ্ট সীমানার ভেতরের একটা business এলাকা। "Order service" শুধু order নিয়ে ভাবে, "Inventory service" শুধু stock নিয়ে। তারা একে অপরের database-এ সরাসরি হাত দেয় না; দরকার হলে API-র মাধ্যমে চায়।

কীভাবে কাজ করে

Database per service

সবচেয়ে গুরুত্বপূর্ণ নিয়ম: প্রতিটি সেবার নিজস্ব database। Order service-এর জন্য একটা, Payment service-এর জন্য আরেকটা। এতে এক সেবার schema বদলালে অন্যটা ভাঙে না, আর প্রতিটি সেবা তার data-র একমাত্র মালিক থাকে।

সেবাগুলো কীভাবে কথা বলে

ধরন	উদাহরণ	কখন ভালো	ঝুঁকি
Synchronous	REST, gRPC	তাৎক্ষণিক উত্তর দরকার	একটা সেবা slow হলে অন্যটা আটকে যায়
Asynchronous	Kafka, RabbitMQ	উত্তরের জন্য অপেক্ষা না করলেও চলে	eventual consistency, জটিলতা

Asynchronous Messaging-এ এক সেবা একটা message/event ছেড়ে দেয় আর অন্যরা পরে সেটা পড়ে — এতে সেবাগুলো একে অপরের উপর কম নির্ভরশীল থাকে।

Service Discovery

সেবাগুলো scale করলে তাদের IP ঠিকানা বদলায়। তখন এক সেবা আরেকটাকে কীভাবে খুঁজে পাবে? এর সমাধান Service Discovery — একটা রেজিস্ট্রি (যেমন Consul, বা Kubernetes-এর built-in DNS) যেখানে প্রতিটি সেবা নিজেকে নিবন্ধন করে, আর অন্যরা নাম দিয়ে খুঁজে নেয়।

API Gateway

Client কি ৩০টা আলাদা সেবার ঠিকানা মনে রাখবে? না। সামনে বসে একটা API Gateway — একক প্রবেশদ্বার। ধাপগুলো:

1. Client request পাঠায় gateway-তে।
2. Gateway authentication ও rate-limiting করে।
3. সঠিক সেবায় request রুট করে।
4. দরকারে কয়েকটা সেবার উত্তর জোড়া দিয়ে একটা response ফেরত দেয়।

সুবিধা ও অসুবিধা

সুবিধা:

• স্বাধীন deploy: এক টিম তাদের সেবা deploy করতে অন্যদের জন্য অপেক্ষা করে না।
• লক্ষ্যভিত্তিক scaling: শুধু যে সেবায় চাপ, সেটাকেই scale করা যায়।
• প্রযুক্তির স্বাধীনতা: এক সেবা Java, আরেকটা Go বা Python — যেটা মানানসই।
• Fault isolation: এক সেবা ক্র্যাশ করলে পুরো সিস্টেম না-ও পড়তে পারে।
• ছোট কোডবেইজ: বুঝতে ও রক্ষণাবেক্ষণে সহজ।

অসুবিধা:

• Distributed system-এর জটিলতা: নেটওয়ার্ক ব্যর্থ হয়, latency বাড়ে, debugging কঠিন।
• Data consistency: একাধিক database জুড়ে transaction কঠিন (Saga লাগে)।
• Operational ভার: monitoring, logging, deployment, CI/CD — অনেক বেশি tooling দরকার।
• নেটওয়ার্ক খরচ: সেবার মধ্যে অনেক call, ফলে overhead।
• শুরুর খরচ বেশি: ছোট টিমের জন্য অপ্রয়োজনীয় বোঝা হতে পারে।

কখন ব্যবহার করবে / করবে না

ব্যবহার করবে যখন: অনেক বড় টিম একসাথে কাজ করছে, ভিন্ন অংশের scaling-প্রয়োজন আলাদা, আর product যথেষ্ট পরিণত যে business সীমানাগুলো স্পষ্ট। বড়, দ্রুত বর্ধনশীল কোম্পানির জন্য আদর্শ।

এড়িয়ে যাবে যখন: স্টার্টআপ বা ছোট টিম, এখনো product-market fit খুঁজছ, কিংবা business সীমানা এখনো ঘোলাটে।

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

Netflix microservices-এর সবচেয়ে বিখ্যাত উদাহরণ। তাদের ৭০০-র বেশি সেবা আছে — একটা সেবা শুধু "তুমি কোথায় ভিডিও থামিয়েছ" মনে রাখে, আরেকটা recommendation দেয়, আরেকটা billing সামলায়। ২০০৮-এ একটা বড় database crash তাদের কয়েক দিন ডুবিয়ে দেয়; এরপরই তারা monolith থেকে microservices-এ যায়।

আজ Netflix-এ একটা সেবা ডাউন হলেও (যেমন recommendation), তুমি তবু ভিডিও দেখতে পারবে — হয়তো শুধু সাজেশন কম দেখবে। এটাই fault isolation-এর শক্তি। তারা Eureka (service discovery), Zuul (API gateway) এর মতো টুল বানিয়েছে যেগুলো এখন পুরো ইন্ডাস্ট্রিতে অনুপ্রেরণা।