মাইক্রোসার্ভিস প্যাটার্ন: সিস্টেমকে পানির মতো সহজ করার ৪টি উপায়!

কাল রাতে এক ছোট ভাইয়ের সাথে কথা হচ্ছিল। সে খুব শখ করে তার মনোলিথিক অ্যাপটাকে ছোট ছোট মাইক্রোসার্ভিসে ভাগ করেছে। কথা প্রসঙ্গে বললেন যে আগে একটা বড় বিপদে পড়লে অন্তত জানতেন কোথায় আগুন লেগেছে। এখন অবস্থা এমন হয়েছে যে আগুন এক জায়গায় লাগে আর ধোঁয়া বের হয় অন্য তিন সার্ভিস থেকে। অবস্থা এমন দাঁড়িয়েছে যে কোন সার্ভিসের ডাটা কার কাছে আছে সেটা খুঁজতে খুঁজতেই অর্ধেক দিন পার হয়ে যায়। আসলে সে মাইক্রোসার্ভিস বানাতে গিয়ে অজান্তেই একটি ডিস্ট্রিবিউটেড মনোলিথ অ্যাপ তৈরি করে ফেলেছে যা মেইনটেইন করা এখন তার জন্য এক বিশাল প্যারা।

মাইক্রোসার্ভিস বানানো মানে শুধু কোড আলাদা করা নয়, বরং ডাটা আর লজিককে বুদ্ধি খাটিয়ে সাজানো। এই সমস্যার সমাধান দিতেই ইঞ্জিনিয়াররা কিছু বিশেষ প্যাটার্ন ফলো করেন যা আপনার সিস্টেমকে করবে একদম পানির মতো সহজ। চলুন ২০২৬ সালের লেটেস্ট কন্টেক্সটে আমরা এমন ৪টি প্যাটার্ন নিয়ে আড্ডা দেই যা আপনার ডেভেলপমেন্ট জার্নিকে অনেক বেশি স্মুথ করে দেবে।

১. ডাটাবেজ পার সার্ভিস এই প্যাটার্নটির মূল কথা হলো প্রতিটি মাইক্রোসার্ভিসের নিজস্ব আলাদা ডাটাবেজ থাকবে। ধরুন অর্ডার সার্ভিস আর ইউজার সার্ভিস একদম আলাদা। এখানে নিয়ম হলো অর্ডার সার্ভিস কখনোই সরাসরি ইউজারের ডাটাবেজে কুইরি করতে পারবে না। তার যদি কোনো তথ্যের প্রয়োজন হয় তবে ইউজারের এপিআই কল করেই সেটি নিতে হবে।

এতে সবচেয়ে বড় সুবিধা হলো ডাটা আইসোলেশন। একটি সার্ভিসের ডাটাবেজ স্ট্রাকচার আপডেট করলে অন্য সার্ভিসে এর কোনো প্রভাব পড়ে না। তবে বড় চ্যালেঞ্জ হলো ডাটা কনসিস্টেন্সি বজায় রাখা। যখন একটি ট্রানজেকশন অনেকগুলো সার্ভিসের ওপর নির্ভর করে তখন আপনাকে সার্ভিসগুলোর মধ্যে কমিউনিকেশন নিয়ে অনেক বেশি সচেতন থাকতে হয়। এটি সিস্টেমকে কিছুটা জটিল করলেও বড় টিমের জন্য এটিই স্ট্যান্ডার্ড।

২. শেয়ারড ডাটাবেজ অনেক এক্সপার্ট একে অ্যান্টি প্যাটার্ন বললেও বাস্তব জীবনে এটি বেশ কাজের। বিশেষ করে যখন আপনি একটি পুরনো বিশাল অ্যাপ্লিকেশনকে ধীরে ধীরে মাইক্রোসার্ভিসে নিয়ে যাচ্ছেন। এখানে অনেকগুলো সার্ভিস একটি কমন ডাটাবেজ ব্যবহার করে।

এটি ব্যবহার করা খুব সহজ কারণ আপনাকে রাতারাতি ডাটাবেজ আর্কিটেকচার পাল্টাতে হচ্ছে না। কিন্তু লং টার্ম এটি বেশ রিস্কি হতে পারে। এক টিমের করা ছোট একটি টেবিল পরিবর্তন অন্য সব টিমের সার্ভিসকে এরর খাওয়াতে পারে। এছাড়া রানটাইম কনফ্লিক্ট হওয়ার ভয় তো থাকেই। তাই একে কেবল মাইগ্রেশনের শুরুর ধাপ হিসেবে ব্যবহার করাই হবে বুদ্ধিমানের কাজ।

৩. এপিআই কম্পোজিশন মাইক্রোসার্ভিসে যখন ডাটা আলাদা হয়ে যায় তখন ক্লায়েন্টের জন্য সব তথ্য এক জায়গায় দেখানো কঠিন হয়ে পড়ে। ধরেন আপনার ফ্রন্টএন্ডে এমন একটা পেজ দেখাতে হবে যেখানে ইউজারের প্রোফাইল এবং তার করা সব অর্ডারের লিস্ট একসাথে থাকবে। এখানে কাজ করে এপিআই কম্পোজার।

সে সব প্রয়োজনীয় সার্ভিসকে আলাদা আলাদা কল করে ডাটা নিয়ে আসে। তারপর মেমোরিতে বসে সবগুলোকে এক সুতোয় গেঁথে একটি কমপ্লিট ডাটা হিসেবে ক্লায়েন্টকে ফেরত দেয়। এটি খুব জনপ্রিয় একটি সমাধান হলেও ডাটা সাইজ অনেক বড় হলে মেমোরির ওপর চাপ ফেলতে পারে। তাই বড় ডাটা হ্যান্ডেল করার সময় কোড অপ্টিমাইজেশনের দিকে বাড়তি নজর দিতে হয়।

৪. CQRS এবং ইভেন্ট সোর্সিং CQRS মানে হলো কমান্ড এবং কুয়েরি আলাদা করা। সহজ কথায় বলতে গেলে ডাটা সেভ করার জন্য আপনি একটি ডেডিকেটেড রাস্তা ব্যবহার করবেন আর ডাটা দেখানোর জন্য একদম আলাদা আরেকটি অপ্টিমাইজড ডাটাবেজ বা রাস্তা ব্যবহার করবেন। এটি তখন খুব কার্যকর হয় যখন আপনার অ্যাপে ডাটা দেখার রিকোয়েস্ট অনেক বেশি থাকে কিন্তু আপডেট করার কাজ কম থাকে। এর ফলে আপনি রিড এবং রাইট অপারেশনগুলোকে আলাদাভাবে স্কেল করতে পারেন।

এর সাথে যখন ইভেন্ট সোর্সিং যোগ হয় তখন আপনি ডাটাটি কীভাবে এই অবস্থায় আসলো তার পুরো হিস্ট্রি ইভেন্ট আকারে সেভ করে রাখেন। এটি অডিট ট্রেইল বা সিস্টেম রিকভারির জন্য জাস্ট অস্থির একটি সমাধান। তবে এটি মেইনটেইন করার জন্য কিছুটা অভিজ্ঞ টিমের প্রয়োজন হয় কারণ এখানে অনেকগুলো মুভিং পার্টস থাকে যা নিয়মিত মনিটর করতে হয়।

আমি মনে করি যে আর্কিটেকচার হওয়া উচিত আপনার অ্যাপের প্রয়োজনের ওপর ভিত্তি করে। আপনার অ্যাপের যদি ইউজার সংখ্যা খুব বেশি না হয় তবে জোর করে মাইক্রোসার্ভিসে যাওয়ার কোনো মানে নেই। সিস্টেম যত সিম্পল থাকবে আপনার ডেভেলপমেন্ট লাইফ তত সহজ হবে।