လွယ်လွယ်ပြောရရင် Event-Driven Architecture ဆိုတာ program ရဲ့ အစိတ်အပိုင်းတွေက တစ်ခုနဲ့တစ်ခု တိုက်ရိုက် မခေါ်ဘဲ၊ “ဒါ ဖြစ်သွားပြီ” ဆိုတဲ့ event (အဖြစ်အပျက်) လေးတွေကို ကြားခံနယ်ကနေတစ်ဆင့် ပို့ပြီး အလုပ်လုပ်တဲ့ ဒီဇိုင်းပုံစံပါ။

ကျွန်တော် ဒါကို ပထမဆုံး သဘောပေါက်သွားတုန်းက food delivery app ကို ကြည့်မိတာပါ။ သင် foodpanda မှာ မုန့်မှာလိုက်တယ် — အဲဒီနောက်ကွယ်မှာ ဘာတွေ ဖြစ်သွားလဲ စဉ်းစားကြည့်ပါ။ ဆိုင်က အမှာစာ လက်ခံတယ်၊ rider ကို ရှာတယ်၊ ငွေရှင်းတယ်၊ သင့်ဆီ notification ပို့တယ်။ အဲဒီအလုပ်တွေအားလုံးက တစ်ခုပြီးတစ်ခု တိုက်ရိုက် ခေါ်နေတာလား? မဟုတ်ဘူး — event တွေနဲ့ ချိတ်ဆက်ထားတာပါ။

စားသောက်ဆိုင်က Order စာရွက်နဲ့ ရှင်းပြမယ်

အရင်နည်းကို အရင်ပြောမယ်။ စားပွဲထိုးက ဧည့်သည်ဆီက order ယူတယ်၊ မီးဖိုချောင်ကို သွားပြောတယ်၊ ဟင်းချက်ပြီးတဲ့အထိ မီးဖိုချောင်နားမှာ ရပ်စောင့်တယ်၊ ဟင်းရလာမှ စားပွဲဆီ ပြန်သယ်လာတယ်။ ဒါကို Request-Response လို့ ခေါ်တယ် — တစ်ခုပြီးမှ တစ်ခု၊ စောင့်နေရတယ်။

Event-driven နည်းကတော့ ဒီလိုပါ။ စားပွဲထိုးက order စာရွက်လေးကို မီးဖိုချောင်ရဲ့ order board ပေါ်မှာ ကပ်လိုက်တယ်၊ ပြီးတော့ တခြား စားပွဲဆီ သွားတယ်။ မီးဖိုချောင်က board ပေါ်မှာ စာရွက်အသစ် ပေါ်လာတာကို မြင်တာနဲ့ ချက်တယ်။ ချက်ပြီးရင် “ဟင်းအဆင်သင့်” ဆိုတဲ့ စာရွက်လေး board ပေါ် ပြန်ကပ်တယ်။ စားပွဲထိုးက အဲဒါကို မြင်တာနဲ့ လာယူတယ်။ ဘယ်သူမှ ဘယ်သူ့ကိုမှ ရပ်စောင့်မနေဘူး — စာရွက်လေးတွေနဲ့ပဲ ဆက်သွယ်တယ်။

Software မှာလည်း အတူတူပဲ။ “OrderPlaced” ဆိုတဲ့ event တစ်ခု ဖြစ်လာတယ်။ အဲဒီ event ကို စိတ်ဝင်စားတဲ့ service တိုင်းက ကိုယ့်ဘာသာ လက်ခံပြီး ကိုယ့်အလုပ် ကိုယ်လုပ်တယ် — ဆိုင်က ချက်တယ်၊ ငွေရှင်းတဲ့ service က ငွေကောက်တယ်၊ notification service က သင့်ဆီ message ပို့တယ်။ တစ်ခုခုပျက်သွားရင်တောင် ကျန်တာတွေ ဆက်အလုပ်လုပ်နေတယ်။

တကယ့် ဥပမာ ၃ ခု

၁။ Food Delivery App

သင် order တင်လိုက်တာနဲ့ “OrderPlaced” event တစ်ခု ထွက်တယ်။ ဆိုင်က အဲဒါကို ကြားပြီး ချက်တယ်။ Rider system က အနီးဆုံး rider ကို ရှာတယ်။ Payment system က ငွေဖြတ်တယ်။ သင့်ဆီ “ဆိုင်က လက်ခံလိုက်ပြီ” ဆိုတဲ့ notification ရောက်တယ်။ ဒါတွေအားလုံးက တစ်ခုနဲ့တစ်ခု တိုက်ရိုက် မသိဘဲ event ကနေတစ်ဆင့် ချိတ်ဆက်ထားတာပါ။

၂။ GitHub က Webhook

GitHub မှာ code push လုပ်လိုက်တာနဲ့ “push” event တစ်ခု ထွက်တယ်။ သင် ကြိုပြီး ချိတ်ထားတဲ့ server က အဲဒီ event ကို ကြားတာနဲ့ test တွေ run တယ်၊ site ကို auto deploy လုပ်တယ်။ သင် ဘာမှ ထပ်နှိပ်စရာ မလိုဘူး — push လုပ်လိုက်တာနဲ့ ကျန်တာ အလိုလို ဖြစ်သွားတယ်။

၃။ E-commerce မှာ Stock လျော့တာ

လူတစ်ယောက် ပစ္စည်းတစ်ခု ဝယ်လိုက်တာနဲ့ “OrderCompleted” event ထွက်တယ်။ Warehouse system က အဲဒါကို ကြားပြီး stock ကို တစ်ခု လျှော့တယ်။ Stock က ၁၀ အောက်ရောက်သွားရင် “LowStock” event ထပ်ထွက်တယ်၊ အဲဒါကို supplier system က ကြားပြီး ပစ္စည်းအသစ် မှာတယ်။ ဒီလို ဆက်တိုက်သွားတာပါ။

သုံးတဲ့ Tool တွေ

Message Queue (RabbitMQ, SQS) — event တွေကို တန်းစီပြီး ပို့ပေးတဲ့ စာတိုက်ပုံးကြီးလို
Kafka — event တွေကို အများကြီး၊ မြန်မြန်ဆန်ဆန် ပို့ပေးနိုင်တဲ့ စနစ်၊ Netflix, LinkedIn တို့သုံးတယ်
Webhook — အရိုးရှင်းဆုံး event ပုံစံ၊ HTTP request တစ်ခုနဲ့ “ဒါ ဖြစ်သွားပြီ” လို့ ပြောတာ

အားသာချက်နဲ့ အားနည်းချက်

အားသာချက်က ရှင်းပါတယ်—

service တစ်ခုပျက်လည်း ကျန်တာတွေ ဆက်အလုပ်လုပ်တယ် (တစ်ခု ပြိုရင် အားလုံး မပြိုဘူး)
အလုပ်များလာရင် လိုတဲ့ service ကိုပဲ ခွဲပြီး တိုးချဲ့နိုင်တယ်
service အသစ်တစ်ခု ထပ်ထည့်ချင်ရင် event ကို နားထောင်ရုံပဲ၊ ရှိပြီးသား code ကို ပြင်စရာ မလိုဘူး

ဒါပေမယ့် အလကား မရဘူး—

event တွေ မှားတဲ့အစီအစဉ်နဲ့ ရောက်လာရင် ပြဿနာ တက်နိုင်တယ် (ငွေရှင်းပြီးမှ order ပယ်ဖျက်တာမျိုး)
တစ်ခုခု မှားသွားရင် ဘယ်နေရာမှာ မှားတာလဲ ရှာရတာ ခက်တယ် — event တွေ ဘယ်လို စီးဆင်းသွားလဲ လိုက်ကြည့်ရတယ်
အစမှာ ဒီဇိုင်း လုပ်ရတာ ပိုရှုပ်တယ်

Event-driven ဆိုတာ “တစ်ခုခု ဖြစ်လာမှ တုံ့ပြန်မယ်” ဆိုတဲ့ ရိုးရှင်းတဲ့ စိတ်ကူးပါ။ ဒါပေမယ့် ဒီရိုးရှင်းတဲ့ စိတ်ကူးကပဲ ဒီနေ့ ကမ္ဘာအကြီးဆုံး app တွေကို အလုပ်လုပ်စေတာပါ။ နောက်တစ်ခါ သင် food delivery မှာပြီး “ဆိုင်က လက်ခံလိုက်ပြီ” ဆိုတဲ့ notification မြင်ရင်၊ အဲဒီနောက်ကွယ်မှာ event တစ်ခုက ခရီးထွက်သွားတာကို သတိရလိုက်ပါ။ 🙂