System Design ဆိုတာဘာလဲ — Course လမ်းညွှန်

နားလည်ထားရမယ့် အချက်

System design ဆိုတာ traffic ဘယ်လောက်ရောက်လာမလဲ၊ latency budget ဘယ်လောက်ရှိလဲ၊ ကုန်ကျစရိတ် ဘယ်လောက်ကန့်သတ်ထားလဲ၊ team size ဘယ်လောက်ရှိလဲ၊ ထုတ်ဝေချိန် ဘယ်လောက်တိုတောင်းလဲဆိုတဲ့ real constraints တွေကို ထည့်သွင်းစဉ်းစားပြီး architecture ရွေးချယ်တဲ့ discipline တစ်ခုပါ — memory ထဲက 'မှန်ကန်တဲ့ architecture' တစ်ခုကို ပြန်ထုတ်ယူတာ မဟုတ်ပါဘူး။ universally correct ဖြစ်တဲ့ design ဆိုတာ တကယ်တော့ မရှိပါဘူး — user တစ်သောင်းအတွက် ကောင်းမွန်တဲ့ solution တစ်ခုဟာ user တစ်သန်းအတွက်ကျတော့ ဖြုန်းတီးတာ ဒါမှမဟုတ် လုံးဝမှားယွင်းတာ ဖြစ်နိုင်သလို၊ whiteboard ပေါ်မှာ လှပတဲ့ pattern တစ်ခုကလည်း engineer သုံးယောက်ပဲရှိတဲ့ team အနေနဲ့ budget ကျဉ်းကျဉ်းနဲ့ တည်ဆောက်လို့ မရနိုင်ဘူးလည်း ဖြစ်နိုင်ပါတယ်။ ဒါက interview အတွက်ပဲ အရေးကြီးတာ မဟုတ်ဘဲ real engineering အတွက်ပါ အရေးကြီးပါတယ် — version ပထမဆုံးထက် ကျော်ပြီး ကြီးထွားလာတဲ့ system တိုင်းဟာ အင်အားချင်းတူညီတဲ့ ပြဿနာတွေကို နောက်ဆုံးမှာ ရင်ဆိုင်ရမှာပါ — server တစ်ခုတည်းက capacity ကုန်သွားတာ၊ database က bottleneck ဖြစ်လာတာ၊ တခြားနိုင်ငံက user တစ်ယောက်အတွက် service က load အောက်မှာ ညံ့ဖျင်းသွားတာ။ outage ဖြစ်ပြီးမှ တုံ့ပြန်နေမယ့်အစား system design က repeatable process တစ်ခုကို ပေးပါတယ် — system က ဘာလုပ်ရမှာလဲ ဖော်ပြပါ၊ ဘယ်လောက် scale ကို ကိုင်တွယ်ရမလဲ estimate လုပ်ပါ၊ ဘယ်နေရာမှာ အရင်ဆုံးကျိုးပဲ့မလဲ ရှာဖွေပါ၊ ပြီးရင် accident အနေနဲ့မဟုတ်ဘဲ deliberate အနေနဲ့ trade-off တွေကို ရွေးချယ်ပါ။ ဒီ course က ဒီ process ကို layer အလိုက် တည်ဆောက်ပေးမှာဖြစ်ပြီး — Basic, Intermediate, Advanced — နောက်ဆုံးမှာ hands-on project သုံးခု: URL shortener, rate-limiter service, notification system တို့မှာ အသုံးချမှာဖြစ်ပြီး standalone exercises တွေလည်း ပါဝင်ပါတယ်။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

သင်လက်ရှိသင်ယူနေတဲ့ Tutorial Platform ကိုယ်တိုင်ဟာ ဒီ concept ရဲ့ real example ပါပဲ — ဒီနေ့ server တစ်ခုတည်းနဲ့ ကောင်းကောင်းအလုပ်လုပ်နေပေမယ့် learner ပိုများလာတာနဲ့အမျှ ဒီ course ထဲက lesson တိုင်းဟာ platform ရဲ့ engineer တွေ ဆုံးဖြတ်ရမယ့် real decision တွေ ဖြစ်လာပါတယ် — request တစ်ခုကို ဘယ် server က ဖြေရမလဲ၊ traffic ကို server တွေအကြား ဘယ်လိုဖြန့်ဝေမလဲ၊ database ကို hit မလုပ်ဘဲ ဘာကို cache လုပ်ထားမလဲ၊ ကမ္ဘာတစ်ဝှမ်းက learner တစ်ယောက်အတွက် lesson ကို ဘယ်လို မြန်မြန်ဆန်ဆန် load ဖြစ်အောင်လုပ်မလဲ။ ဒီ course တစ်လျှောက်လုံးမှာ သင် Tutorial Platform အတွက် ဒီအပိုင်းတွေကို project တစ်ခုချင်းစီအလိုက် design ဆွဲသွားမှာဖြစ်ပြီး learner ထောင်ချီကနေ သန်းချီအထိ ကြီးထွားသွားမှာဖြစ်ပါတယ်။

• System design ဆိုတာ traffic၊ latency၊ ကုန်ကျစရိတ်၊ team size စတဲ့ real constraints တွေကို trade-off လုပ်တာဖြစ်ပြီး 'တစ်ခုတည်းသော မှန်ကန်တဲ့ architecture' ကို ဖြစ်စေတဲ့ subject မဟုတ်ပါ။
• ကြီးထွားလာတဲ့ system တိုင်းဟာ ကြိုတင်စီစဉ်ထားသည်ဖြစ်စေ မထားသည်ဖြစ်စေ bottleneck အတူတူများကို နောက်ဆုံးမှာ ရင်ဆိုင်ရမှာဖြစ်ပါတယ်။
• System design process က requirements ဖော်ပြခြင်း၊ scale estimate လုပ်ခြင်း၊ bottleneck ရှာခြင်း၊ trade-off ကို deliberate ရွေးချယ်ခြင်း ဆိုတဲ့ အဆင့်လေးဆင့်ပါ။

အတူတူ စမ်းရေးကြည့်မယ်

GUESSING AN ARCHITECTURE               SYSTEM DESIGN PROCESS
------------------------------          ------------------------------
"Let's use microservices,               1. State requirements
 sounds modern"                            (traffic, users, latency budget)
        |                                          |
        v                                          v
No reasoning about actual              2. Estimate scale
traffic or team size                       (requests/sec, data size, growth)
        |                                          |
        v                                          v
Arbitrary tech choices,                3. Identify bottlenecks
copied from a blog post                    (where will this break first?)
        |                                          |
        v                                          v
Breaks under real load,                4. Choose trade-offs deliberately
nobody knows why                           (cost vs speed vs complexity)

Diagram က architecture ကို arbitrary ခန့်မှန်းရွေးချယ်ခြင်းနှင့် requirements-based process တစ်ခုနှင့် တွေးတောဆင်ခြင်ရွေးချယ်ခြင်းကြား ကွာခြားချက်ကို ပြသပါတယ်။

Wikipedia — Systems design — System Design