Architectural Patterns: Message Queues & Pub/Sub

ရည်ရွယ်ချက်

Asynchronous Communication အတွက် အဓိက Pattern နှစ်ခုကို လေ့လာရန်နှင့် ၎င်းတို့၏ မတူညီသော အသုံးပြုပုံများကို နားလည်စေရန် ဖြစ်ပါတယ်။

“စာတိုက်ပုံး” - The Message Broker

ဒီ Pattern နှစ်ခုလုံးက Message Broker (ဥပမာ - RabbitMQ, Apache Kafka, AWS SQS) လို့ခေါ်တဲ့ Infrastructure Software တစ်ခုကို ဗဟိုက “စာတိုက်ပုံး” အဖြစ် အသုံးပြုကြပါတယ်။

Pattern 1: Message Queues (တစ်ဦးမှ တစ်ဦးသို့)

• ဘာလဲ - ဒီ Pattern မှာ၊ Producer က “Queue” (တန်းစီ) ထဲကို Message တစ်စောင်ပို့လိုက်ပြီး၊ အဲဒီ Message ကို လက်ခံသူ (Consumer) တစ်ဦးတည်းကသာ ယူပြီး အလုပ်လုပ်ပါတယ်။ ဒါက Command-Based (အမိန့်ပေးခိုင်းစေတဲ့) အလုပ်တွေအတွက် ဒီဇိုင်းဆွဲထားတာပါ။

• ဥပမာနှိုင်းယှဉ်ချက် - Supermarket က ပိုက်ဆံရှင်းတဲ့တန်း - တန်းစီနေတဲ့ Customer တစ်ယောက်ချင်းစီက Message တစ်စောင်ပါ။ အဆင်သင့်ဖြစ်နေတဲ့ ငွေရှင်းကောင်တာက Consumer ပါ။ ငွေရှင်းကောင်တာတစ်ခုက တစ်ကြိမ်မှာ Customer တစ်ယောက်ကိုပဲ ဝန်ဆောင်မှုပေးပါတယ်။

Message ဆိုတာက အလုပ်တစ်ခုလုပ်ဖို့ “အမိန့်ပေးခိုင်းစေချက်” တစ်ခုဖြစ်ပြီး၊ အဲဒီအလုပ်ပြီးသွားရင် Queue ထဲကနေ ဖယ်ရှားလိုက်ပါတယ်။

• အသင့်တော်ဆုံးအသုံးပြုပုံ - တစ်ကြိမ်ပဲ လုပ်ဖို့လိုတဲ့ Background Job တွေအတွက် သင့်တော်ပါတယ်။

  • ဥပမာ - Image Service က “ProcessThisImage” ဆိုတဲ့ Command တစ်ခုကို Queue ကနေ လက်ခံရရှိတယ်။ Worker တစ်ခုက Message ကိုယူ၊ ပုံကို Resize လုပ်၊ ပြီးတော့ Message ကို ဖျက်လိုက်ပါတယ်။

Pattern 2: Publish/Subscribe (Pub/Sub)

• ဘာလဲ - ဒီ Pattern မှာ၊ Publisher က Message (Event) တစ်ခုကို ထုတ်လွှင့်လိုက်ပြီး၊ စိတ်ဝင်စားတဲ့ Subscriber (စောင့်ကြည့်သူ) အားလုံးက အဲဒီ Message တစ်စောင်စီကို လက်ခံရရှိကြပါတယ်။ ဒါက သတင်းအချက်အလက်ကို ဖြန့်ဝေဖို့အတွက် ဒီဇိုင်းဆွဲထားတာပါ။

• ဥပမာနှိုင်းယှဉ်ချက် - မြို့ထဲမှာ သတင်းလိုက်ကြေညာတဲ့သူ - သတင်းကြေညာသူက မြို့လယ်မှာ သတင်းတစ်ခု (“မင်္ဂလာပွဲတော်ကို နောက်အပတ်ကျင်းပမယ်!”) လို့ အော်ဟစ်ကြေညာလိုက်တယ်။ အဲဒီသတင်းကို စိတ်ဝင်စားတဲ့သူတိုင်း—မုန့်ဖုတ်သမား၊ အပ်ချုပ်သမား၊ တည်းခိုခန်းပိုင်ရှင် (Subscribers) —က သင့်တော်သလို တုံ့ပြန်နိုင်ကြတယ်။ စိတ်မဝင်စားတဲ့သူတွေကတော့ သတင်းကို လျစ်လျူရှုလိုက်ရုံပါပဲ။ သတင်းက ဘယ်သူတစ်ဦးတစ်ယောက်ကိုမှ သီးသန့်ညွှန်းပြီး ကြေညာတာမဟုတ်ပါဘူး။

• အသင့်တော်ဆုံးအသုံးပြုပုံ - System ရဲ့ မတူညီတဲ့ အစိတ်အပိုင်းအများအပြားက စိတ်ဝင်စားနိုင်တဲ့ Event တစ်ခုခုဖြစ်ပွားတဲ့အခါ သုံးပါတယ်။ ဒါက Event-Driven Architecture ရဲ့ အခြေခံအုတ်မြစ်ပါပဲ။

  • ဥပမာ - Order Service က “OrderPlaced” Event တစ်ခုကို ထုတ်လွှင့်မယ့်အချိန်ကို Shipping Service က ပစ္စည်းပို့ရန် စောင့်ကြည့်နေနိုင်တယ်၊ Notifications Service က Email ပို့ဖို့ စောင့်ကြည့်နေနိုင်တယ်၊ ပြီးတော့ Analytics Service က အရောင်း Report တွေကို Update လုပ်ဖို့ စောင့်ကြည့်နေနိုင်ပါတယ်။ Service သုံးခုလုံးက တူညီတဲ့ Event တစ်ခုတည်းကို သင့်တော်သလို တုံ့ပြန်ကြတာပါ။