“সবাই মাইক্রো করছে, আমরাও করব”—এই মানসিকতায় লাফ দিলে বেশিরভাগ সময় জিতবেন না। পর্ব ১-এ যা বলেছিলাম—আজটা সেটার পরের ধাপ: কখন মাইক্রো বুদ্ধিমানের কাজ, আর কখন না।
মাইক্রোসার্ভিস শুনতে exciting, কিন্তু আগে বুঝতে হবে কেন, কখন আর কোথায় এটা লাগবে। না বুঝে নিলে লাভের চেয়ে ক্ষতি বেশি—ডিপ্লয়মেন্ট, observability, টিম কোঅর্ডিনেশন সব জায়গায় টাকা আর সময় পোড়ে। “অনেকে করছে বলে আমাদেরও করতে হবে”—এটা decision-making না।
অনেক প্রোজেক্ট মনোলিথ থাকলেই ভালো; জোর করে মাইক্রোতে গেলে কাজ বেড়ে যায়—স্কেলের জন্য pure overkill।
প্রথমে, প্রয়োজনীয়তা বুঝুন
আগে ভাবো: মাইক্রোতে গেলে কী সুবিধা আসবে—ছয় মাস পরে? বিদ্যমান টিম কি নতুন আর্কিটেকচার, টুলিং আর অপারেশনাল বোঝা টানতে পারবে?
নিচের সংকেত থাকলে মাইক্রো নিয়ে গম্ভীরভাবে ভাবা যায়:
- ব্যবহারকারী বেশি, দৈনিক লোড বেশি।
- ট্রাফিক অসম—সার্চ, ফিড, পেমেন্টের মতো এক অংশ আলাদা করে স্কেল করতে হয়।
- বিগ ডাটা বা হেভি কম্পিউটেশন—নির্দিষ্ট অংশে CPU/RAM লাগে, পুরো মনোলিথ স্কেল করা অযৌক্তিক।
- রিলিজ ছোট ইউনিটে, দ্রুত—Agile মানে শুধু স্ট্যান্ডআপ নয়; সার্ভিস অনুযায়ী ক্ষমতা বাড়ানো-কমানো লাগে।
- একাধিক টিম স্পষ্ট বাউন্ডারি নিয়ে প্যারালাল কাজ করছে—এক কোডবেসে সবাই ঢুকে merge conflict আর regression ঝুঁকি বেশি।
আগে মনোলিথ, তারপর মাইক্রো
ডে ওয়ান থেকে “সব মাইক্রো” সাধারণত ভালো আইডিয়া নয়—ডোমেন বাউন্ডারি তখনো পরিষ্কার নয়। টিম খুব দক্ষ আর অপারেশন কালচার mature হলে exception হতে পারে; কিন্তু নেটওয়ার্ক, ডিবাগিং, ডেটা কনসিস্টেন্সি—এই জটিলতা না জেনে আমি কাউকে “চলো মাইক্রো” বলি না।
সময়ের সাথে যে অংশ স্থিতিশীল আর স্বতন্ত্রভাবে deploy করা যায়, সেগুলো ধীরে ধীরে সার্ভিসে তোলা যায়। প্রতিটি সার্ভিস যেন যথাসম্ভব স্বাধীন—টাইট কাপলিং হলে API Gateway ইত্যাদি লাগে; সেসব আলাদা পর্বের বিষয়।
Practical path: একটা মনোলিথ (বা modular monolith) দিয়ে ডোমেন বোঝা, তারপর যেগুলো আলাদা স্কেল/রিলিজ justify করে সেগুলো বের করা। ই-কমার্সে Search, Recommendation, Order, Operations—ভাগ করার কথা তখনই যখন লোড আর টিম স্ট্রাকচার সেটা চায়।
শেষে
পরের লেখায় প্যাটার্ন, অ্যান্টি-প্যাটার্ন, আর যেখানে মাইক্রো “দেখতে ভালো” কিন্তু ব্যয় বেশি—সেগুলো নিয়ে যাওয়া যাবে। প্রশ্ন একটাই: তোমার সমস্যাটা কি স্কেল/টিম/রিলিজ—নাকি শুধু ট্রেন্ড?