Skip to content
GitHub

အသေးစိတ် Design နှင့် အဓိကဆုံးဖြတ်ချက်များ

အဆင့် 6: ဆက်သွယ်မှုပုံစံများကို ရွေးချယ်ခြင်း (Communication Styles)

Section titled “အဆင့် 6: ဆက်သွယ်မှုပုံစံများကို ရွေးချယ်ခြင်း (Communication Styles)”

Service တွေ ခွဲပြီးသွားရင် သူတို့အချင်းချင်း ဘယ်လိုနည်းလမ်းနဲ့ စကားပြောမလဲ (ဆက်သွယ်မလဲ) ဆိုတာ ဆုံးဖြတ်ရပါမယ်။

  • ကားငှားသူက ကားစခေါ်တဲ့အခါ: ကားငှားသူက “ကားခေါ်မယ်” ဆိုတဲ့ ခလုတ်ကို နှိပ်လိုက်ရင်၊ App ကနေ Trip Service ဆီကို ချက်ချင်း အတည်ပြုချက်တောင်းရပါမယ်။ ဒါကြောင့် အဖြေကို ချက်ချင်းစောင့်တဲ့ Synchronous REST API ကို သုံးတာ အကောင်းဆုံးပါ။

  • ကားသမားက တည်နေရာ (Location) ပို့တဲ့အခါ: ကားသမားရဲ့ ဖုန်းကနေ သူ့ရဲ့တည်နေရာကို စက္ကန့်နဲ့အမျှ ဆာဗာဆီကို ပို့ပေးနေရပါမယ်။ ဒါက အမြဲတမ်း ပို့နေရတာဖြစ်လို့ ရိုးရှင်းပြီး မြန်ဆန်တဲ့ WebSockets ဒါမှမဟုတ် gRPC ကို သုံးတာက ပိုသင့်တော်ပါတယ်။

  • ကားသမားဆီကို ကားခေါ်တဲ့အကြောင်း အသိပေးတဲ့အခါ: Trip Service က ကားသမားဆီ အသိပေးစာ (Notification) ရောက်တဲ့အထိ ထိုင်စောင့်နေစရာ မလိုပါဘူး။ “ကားတစ်စီး ခေါ်ထားတယ် (RideRequested)” ဆိုတဲ့ Message ကို ထုတ်လွှင့် (Publish) လိုက်ရုံပါပဲ။ အဲ့ဒီအခါ Asynchronous Event ကို စောင့်ကြည့်နေတဲ့ Notification Service က Message ကို ယူပြီး နီးစပ်ရာ ကားသမားဆီကို ဖုန်းထဲကနေ Notification ပို့ပေးသွားပါလိမ့်မယ်။

အဆင့် 7: Database အမျိုးအစားများ ရွေးချယ်ခြင်း (Polyglot Persistence)

Section titled “အဆင့် 7: Database အမျိုးအစားများ ရွေးချယ်ခြင်း (Polyglot Persistence)”

Service ၅ ခုစလုံးအတွက် Database ကြီးတစ်ခုတည်း မသုံးဘဲ၊ သူ့နေရာနဲ့သူ အသင့်တော်ဆုံး Database ကို ရွေးသုံးပါမယ်။

  • Rider & Driver Services: Profile အချက်အလက်တွေက စည်းမျဉ်းကျကျနဲ့ သေချာသိမ်းဖို့ လိုပါတယ်။ ဒါကြောင့် ဖွဲ့စည်းပုံကျနတဲ့ SQL Database (ဥပမာ - PostgreSQL) ကို သုံးပါမယ်。
  • Trip Service: ခရီးစဉ်တစ်ခုမှာ ပါတဲ့ အချက်အလက်တွေ (ဘယ်ကနေ ဘယ်ကိုသွားတယ်၊ ဘယ်သူမောင်းတယ်၊ ဘယ်လောက်ကျတယ်) က ပြောင်းလဲလွယ်ပါတယ်။ ဒါကြောင့် လိုက်လျောညီထွေဖြစ်တဲ့ Document Database (ဥပမာ - MongoDB) ကို သုံးပါမယ်。
  • Location Service: စက္ကန့်တိုင်း ဝင်လာမယ့် တည်နေရာ Data တွေကို အမြန်ဆုံး ရေးနိုင်ဖတ်နိုင်ဖို့ လိုပါတယ်။ ဒါကြောင့် အလွန်မြန်ဆန်တဲ့ Key-Value (သို့) Geospatial Database (ဥပမာ - Redis) ကို သုံးပါမယ်။

အဆင့် 8: အဓိကဆုံးဖြတ်ချက်တစ်ခုကို ADR ဖြင့် မှတ်တမ်းတင်ခြင်း

Section titled “အဆင့် 8: အဓိကဆုံးဖြတ်ချက်တစ်ခုကို ADR ဖြင့် မှတ်တမ်းတင်ခြင်း”

ဒီလို အရေးကြီးတဲ့ ရွေးချယ်မှုတွေကို “ဘာလို့ ဒီလိုရွေးခဲ့တာလဲ” ဆိုတာ နောက်လူတွေ သိအောင် ADR (Architectural Decision Record) ဆိုတဲ့ မှတ်တမ်းလေး ရေးထားလေ့ရှိပါတယ်။

ADR for Asynchronous events for Ride Request