ইভেন্ট-ড্রিভেন DevOps — মেসেজ কিউ ও ইভেন্ট বাস

১ · কেন প্রোডিউসার-কনজিউমার সরাসরি সংযুক্ত থাকা ঝুঁকিপূর্ণ

একটি সার্ভিস (প্রোডিউসার) যদি আরেকটি সার্ভিসকে (কনজিউমার) সরাসরি, সিনক্রোনাসভাবে কল করে, তাহলে কনজিউমার ধীর হয়ে গেলে বা সাময়িকভাবে ডাউন থাকলে প্রোডিউসারও ব্লক হয়ে যায় বা ব্যর্থ হয় — দুটি সার্ভিসের স্বাস্থ্য একে অপরের সাথে সরাসরি বাঁধা পড়ে যায়। এছাড়াও, একজনকে আপডেট/রিডিপ্লয় করতে হলে অন্যজন ঠিক সেই মুহূর্তে উপলব্ধ থাকতে হবে এমন একটি ভঙ্গুর কো-অর্ডিনেশন তৈরি হয়। মেসেজ কিউMessage Queueপ্রোডিউসার ও কনজিউমারের মাঝে একটি বাফার — প্রোডিউসার বার্তা কিউতে রেখে দেয়, কনজিউমার নিজের গতিতে সেটা তুলে প্রসেস করে; দুজন একে অপরের সাথে সরাসরি সংযুক্ত থাকে না। বা ইভেন্ট বাসEvent Busএকটি পাবলিশ/সাবস্ক্রাইব চ্যানেল — একটি সার্ভিস একটি ইভেন্ট প্রকাশ করে, যেকোনো সংখ্যক আগ্রহী সার্ভিস সেটা সাবস্ক্রাইব করে নিজের মতো প্রতিক্রিয়া জানায়, প্রকাশকারীকে জানতেও হয় না কারা শুনছে। ব্যবহার করলে এই সরাসরি নির্ভরতা দূর হয়ে যায়।

২ · অপারেশনাল বেনিফিট — স্বাধীন ডিপ্লয়, স্বাধীন স্কেল, স্বাধীন ফেইলিওর

৩ · ডেড-লেটার কিউ — ব্যর্থ বার্তার জন্য সেফটি নেট

একটি বার্তা প্রসেস করতে ব্যর্থ হলে দুটি খারাপ বিকল্প আছে — নীরবে বার্তাটি ফেলে দেওয়া (ডেটা হারানো) অথবা অসীমভাবে রিট্রাই করতে থাকা (একটি "পয়জন মেসেজ" পুরো কিউ ব্লক করে রাখতে পারে)। ডেড-লেটার কিউDead-Letter Queue (DLQ)একটি নির্দিষ্ট সংখ্যক রিট্রাইয়ের পরও ব্যর্থ হওয়া বার্তাগুলোর জন্য আলাদা একটি কিউ — বার্তাটি হারিয়ে যায় না, বরং পরে ম্যানুয়ালি পরীক্ষা করার জন্য জমা থাকে। এই দুই সমস্যারই সমাধান — একটি নির্দিষ্ট সীমা (max_retries) পর্যন্ত রিট্রাই করা হয়, তারপরও ব্যর্থ হলে বার্তাটি DLQ-তে সরিয়ে রাখা হয়, প্রধান কিউ ব্লক হয় না, এবং কোনো ইঞ্জিনিয়ার পরে DLQ দেখে ব্যর্থতার কারণ খুঁজে বের করতে পারেন।

# ইভেন্ট-ড্রিভেন প্রসেসিং — রিট্রাই ও ডেড-লেটার কিউ সিমুলেশন (illustrative, কোনো real message broker নয়)
dead_letter_queue = []
attempt_counter = {101: 0, 102: 0}

def flaky_handler(msg):
    # msg 101 তৃতীয় চেষ্টায় সফল হয়, msg 102 কখনোই সফল হয় না (ফেক হ্যান্ডলার)
    attempt_counter[msg["id"]] += 1
    if msg["id"] == 101 and attempt_counter[msg["id"]] >= 3:
        return "success"
    return "failure"

def process_message(msg, handler, max_retries=3):
    attempts = 0
    while attempts < max_retries:
        attempts += 1
        result = handler(msg)
        if result == "success":
            return f"বার্তা #{msg['id']} সফল — {attempts} নং চেষ্টায়"
        print(f"  চেষ্টা {attempts}/{max_retries} ব্যর্থ — বার্তা #{msg['id']}")
    dead_letter_queue.append(msg)
    return f"বার্তা #{msg['id']} {max_retries} বার ব্যর্থ — dead-letter queue-তে পাঠানো হলো"

msg_a = {"id": 101, "payload": "অর্ডার-আপডেট ইভেন্ট"}
msg_b = {"id": 102, "payload": "পেমেন্ট-কনফার্মেশন ইভেন্ট"}

print(process_message(msg_a, flaky_handler, max_retries=3))
print(process_message(msg_b, flaky_handler, max_retries=3))
print("Dead-letter queue-তে থাকা বার্তার id:", [m["id"] for m in dead_letter_queue])

৪ · CI/CD পাইপলাইনে এই প্যাটার্নের ব্যবহার

এই ঠিক প্যাটার্নটি বাস্তব DevOps পাইপলাইনেও দেখা যায় — একটি ডিপ্লয়মেন্ট-সম্পন্ন ইভেন্ট একটি নোটিফিকেশন সার্ভিসে সারিবদ্ধ হতে পারে (স্ল্যাক অ্যালার্ট পাঠানোর জন্য), একটি ইমেজ-স্ক্যান-সম্পন্ন ইভেন্ট ডিপ্লয়মেন্ট পাইপলাইনকে এগিয়ে যেতে বলতে পারে, অথবা একটি ইনফ্রাস্ট্রাকচার-প্রভিশনিং রিকোয়েস্ট একটি কিউতে সারিবদ্ধ হয়ে প্রসেস হতে পারে। প্রতিটি ক্ষেত্রে একই নীতি প্রযোজ্য — সাময়িক ব্যর্থতা রিট্রাই দিয়ে সামলানো, এবং ক্রমাগত ব্যর্থতা DLQ-তে গিয়ে একজন মানুষের নজরে আসা (M10/L44-এর অ্যালার্টিং প্র্যাকটিসের সাথে সরাসরি সম্পর্কিত)।