ব্যর্থ হলেও সামলে নিতে পারে এমন মাইক্রোসার্ভিস

মাইক্রোসার্ভিস আঁকা সহজ, চালানো কঠিন। আসল কাজ শুরু হয় যখন কোনো dependency ধীর হয়ে যায়, একটি বার্তা দুবার আসে অথবা deployment-এর পরে একই সময়ে API-এর দুটি সংস্করণ চলতে থাকে।

ব্যর্থতাকে মাথায় রেখে নকশা করুন #

দূরের একটি সার্ভিসে কল কখনো স্থানীয় function call-এর সমতুল্য নয়। প্রতিটি রিকোয়েস্টের deadline দিন, শুধু নিরাপদে পুনরাবৃত্তি করা যায় এমন operation-এ retry করুন এবং jitter-সহ exponential backoff ব্যবহার করুন। বাজেটহীন retry একটি অসুস্থ সার্ভিসের সমস্যাকে পুরো সিস্টেমের incident-এ পরিণত করতে পারে।

Event প্রসেসিং আইডেমপোটেন্ট করুন #

Event-driven সিস্টেমে একই বার্তা একাধিকবার পৌঁছাবে ধরে নেওয়া উচিত। প্রতিটি event-এ স্থিতিশীল identifier দিন এবং business transaction-এর পাশে প্রসেস করা identifier সংরক্ষণ করুন। এতে consumer একই প্রভাব আবার ঘটানো ছাড়াই পুনরাবৃত্ত বার্তার স্বীকৃতি দিতে পারে।

সিস্টেমের সীমাগুলো পর্যবেক্ষণযোগ্য করুন #

Structured log, correlation ID, latency histogram এবং queue-depth metric সার্ভিসের boundary-তে কী হচ্ছে তা দৃশ্যমান করে। Observability চালুর পরে যোগ করা সাজসজ্জা নয়; এটি ইন্টারফেসের অংশ।

লক্ষ্য প্রতিটি ব্যর্থতা ঠেকানো নয়। লক্ষ্য হলো ব্যর্থতাকে সীমাবদ্ধ রাখা, ব্যাখ্যা করতে পারা এবং সেখান থেকে পুনরুদ্ধার করতে পারা।