SWE ကဘာလို့ system design သိဖို့လိုတာလဲ

Category: mm

SWE တွေ system design ကိုဘာလို့နားလည်သင့်တာလဲဆိုတာနဲ့ပတ်သက်ပြီးရေးချင်လို့ပါ။ လက်ရှိအလုပ်မှာလဲ SWE တချို့က system နဲ့ပတ်သက်လာရင်နားမလည်တဲ့သူတွေရှိပါတယ်။ တချို့ကလဲထင်မှာပါ software engineer ပဲ code ရေး Git repository ကို push နောက်ကျန်တဲ့အပိုင်းက devops team နဲ့ပဲဆိုင်တယ်ဆိုတာမျိုးကကျွန်တော့်အမြင်တော့မှန်တယ်မထင်ဘူး။ System design နားမလည်ရင် app scale သာအပြင် production မှာ application debug လုပ်တဲ့နေရာမှာပါသွားအားနည်းတယ်။ ပြဿနာတစ်ခုတက်ရင်ဘယ်ကစဖြစ်တာလဲဆိုတာကို trace လုပ်တတ်ဖို့လိုတယ်။

ကျွန်တောင်ကိုယ်တိုင်က full-stack နဲ့စခဲ့တယ်နောက် backend ဘက်ကနေ start-up ဖြစ်နေတော့ devops ပိုင်းပါလုပ်ရတယ် (ငါအလုပ်မဟုတ်ဘူးမင်းပဲလုပ်ဆိုပြီးလဲလက်ညှိုးထိုးစရာလူများများစားစားမှမရှိတာ startup က role တော်တော်များများကိုလုပ်ရတာသိပ်တော့မဆန်းပါဘူး၊ နောက်ကောင်းတာက SWE ပိုင်းအပြင် system design ကိုပါပိုပြီးနားလည်လာတယ်)

ဒီ post က system design ကိုသင်ပေးမယ့် post မဟုတ်ပါဘူး။ System design ကဘာလို့ software engineer အနေနဲ့ junior level ကတက်တဲ့အခါကနားလည်ဖို့လိုအပ်လဲဆိုတာကရေးချင်တာပါ။ Junior level လောက်မှာ API လေးတွေရေးမယ် UI လေးတွေဆောက်မယ်ဒီလောက်လုပ်နိုင်ရင်အဆင်ပြေပေမယ့် experience လေးလဲရလာနောက်ကိုယ်က company အကြီးတွေဥပမာ Tier 1, Tier 2 company တွေသွားဖို့ လုပ်ပြီဆို interview မှာ system design round ကပါကိုယ်ပါလာပါတယ်။ ဘယ်လိုမှကိုပြေးလို့မရပါဘူး။ Fresh grad interview တွေမှာသာ Leetcode လောက်နဲ့ပြီးပေမယ့် 2-3 years experience ရှိပြီးသားသူလျှောက်ရင် sysdesign က round 2 or 3 မှာပါလာပါတယ်။

Product တခုရေးတဲ့အခါ code လေးရေးရုံနဲ့မပြီးပါဘူး၊ အဲ့ service ကိုဘယ်လို scale လုပ်မယ်နောက် system မှာ bottle-neck တွေကဘာတွေဖြစ်နိုင်သလဲ၊ global product ဆို API calls တွေကိုဘယ်လို optimize လုပ်မယ်၊ database calls တွေကိုလဲဘယ်လို optimize လုပ်မလဲဆိုတာသိဖို့လိုလာပါတယ်။ ဥပမာ tiktok လို app မျိုးက asia ကဆိုပေမယ့် US ကလူကလှမ်းသုံးရင် latency နည်းအောင်ဘယ်လိုလုပ်မလဲစတာတွေပေါ့။

တကယ်တန်း SWE အနေနဲ့ mid-senior သွားရင်အခြားနားလည်ထားသင့်တဲ့ skill set က sys design အပြင် test ကျန်သေးတယ်။ Unit test နဲ့ Integration test ကဘာကွာလဲနောက် End-2-End test. သူတို့ရဲ့ trade-off တွေကဘာလဲ။ app တစ်ခုမှာဘာလို့ unit test ကအများဆုံးရှိသင့်တာလဲ။ Test pyramid model နားလည်ဖို့တွေ။
Test အပိုင်းတော့နောက်မှသတ်သတ်ရေးမယ်၊ အခုက sys design post ဆိုတော့။

နောက်ဥပမာထပ်ပေးရမယ်ဆို instagram ဆိုပါစို့အဲ့မှာ news feed ရှိတယ်သူက algorithm ကနေပြီးတော့ user တိုင်းအတွက် personalized feed ထုတ်ပေးတယ်။ အဲ့ personalized feed ကို user က home သွားတိုင်း database ကနေ data ဆွဲထုတ်ပြီး algorithm နဲ့တွက်နောက် user ကို response ပြန်မှာလား?（spolier: nope!, အဲ့လိုသာအမြဲထိုင်တွက်နေရရင်သေရချည်ရဲ့ ဆိုတော့ဘယ်လိုလုပ်မလဲ, caching လုပ်မယ်) ဟုတ်ပြီးအဲ့တာဆို ဘာ caching strategy သုံးမှာလဲ（LIFO, FIFO, LRU, LFU)။ IG feed ကိုတော့ LFU/LRU ကအသင့်တော်ဆုံးပဲ။

ဒါက news feed အပိုင်းနောက် database, ဒါလဲပြောစရာတော်တော်များတယ်။ Application သေးသေးလေးတွေမှာ database ကို instance တစ်ခုနဲ့ run လိုရပေမယ့်ခုနကလို instagram မျိုးကိုသွား run ရင်မရပါဘူး။ ဆိုတော့ write replica/read replica ခွဲမယ်ဘာလို့လဲ။ Instagram မှာဆို account မဖွင့်ပဲသုံးမယ့် ghost users တွေရှိမယ်၊ read access ကထားပါတော့ပိုများမယ်၊ ဒီတော့ write လုပ်တာနဲ့၂ခုလုံးက peak ကို database calls တွေ slowdown ဖြစ်နိုင်တယ်အဲ့တော့ခုနကလို read/write replica ခွဲမယ်ပေါ့။ ဒါတောင်မပြီးသေးပါဘူး indexing နောက် sharding ကျန်သေးတယ်။ indexing ကလဲ trade-off နားလည်ဖို့လိုတယ်။ indexing ကြောင့် read မြန်လာပေမယ့် ရှိသမျှအကုန် indexing လုပ်ရင် write တိုင်း index update ဖို့လိုလာမယ်ဒီတော့ write ကနှေးလာမယ်။ ဒါကိုလဲကိုယ် design မယ် system ပေါ်မူတည်ပြီးနားလည်ဖို့လိုတယ်။

ပြီးတော့အကျမ်းဖြင်း resource requirement လဲတွက်တတ်ဖို့လိုတယ်။ ဥပမာ tiktok က 20 seconds, 720p video ပေး upload တယ်ထား 10 millions users ဆိုတစ်နှစ်မှာ storage ဘယ်လောက်လိုလဲဆိုအကြမ်းဖြင်းတွက်တတ်ဖို့လိုတယ်။

30fps, 720p က 20 seconds ကို 20mb ထား လူတိုင်း၁နေ့ video တစ်ခု upload မယ်ဆို (လူတိုင်းကတစ်နေ့တခုတင်မှာမဟုတ်ပေမယ့် ၂-၃ တင်တဲ့သူနဲ့ဆို average, 1 person 1 video ယူလိုက်တာ)
20mb * 365 * 10 million = 73 petabyte အတိအကျဖြစ်စရာမလိုဘူး but အကြမ်းဖြင်းတွက်တတ်ဖို့လိုမယ်။ ဒါတောင် 720p ကို 480p ပြောင်းသိမ်းတာ video processing တွေမပါသေးဘူး

ပြီးတော့အဲ့ processed လိုက်တဲ့ video ကို s3 လို object storage မှာသိမ်းပြီး user ကိုတမ်း serve မှာလား၊ မဟုတ်ရင်ရှေ့က CDN ကို caching အနေနဲ့ဘာလို့ခံမှာလဲ။ နောက်အဲ့တာကို cache အဖြစ်သုံးပြီဆိုဘယ်အချိန် update ကမယ်ဆိုတာဘယ်လိုသိမှာလဲ။ (answer： use message queue).

နောက် sharding.. 10 millions users တွေကို database တခုထဲသိမ်းမှာလားမဟုတ်ရင် node 4 ခုထားသိမ်းမယ်ဒါဆို user ABC က node 1 မှာဆိုတာဘယ်လိုသိမလဲ၊ အဲ့လိုသိဖို့ဆို consistent hashing ကိုသုံးမယ်ပေါ့။ ပြီးတော့ vertical partitions နဲ့ horizontal partitions နဲ့ကျန်သေးတယ်။ vertical partition က column လိုက်ခွဲသိမ်းတာမျိုး။

ထားတော့ဒါဆို caching နဲ့ database ပြီးပြီ၊ LB, load-balancer ဘက်လှည့်မယ်။ ဒီမှာလဲ LB ဆို in-depth သွားလို့ရသေးတယ်။ Load-balance techniques မှာဘာတွေသုံးမှာလဲ။ least connection လား least response time လား round robin လား IP hashing နဲ့လားဒါနဲ့ပဲလားဆိုတော့ No! API ကိုလဲ read nodes, write nodes ခွဲလို့ရသေးတယ်။ ဘာလို့လဲဆို write nodes တွေက database မ save ခင် may be တခုခုအရင် compute လုပ်မယ်၊ အဲ့တာကလဲ slow down ဖြစ်နိုင်တယ် ဆိုတော့ read/write nodes တွေခွဲလိုက်ရင် write nodes က compute လုပ်လဲ read ကိုလာပြီး affect မဖြစ်တော့ဘူး။

နောက် read API ကို database call အမြဲမလုပ်အောင် memcache/redis ရှေ့ကခံတယ်ထား cache invalidation ကိုကောဘယ်လို handle မှာလဲ။ Data update ကို cache မှာရေးနောက် database မှာသွားရေးပြီးမှ user ကို response ပြန်မှာလား အဲ့တာဆို 2 write calls ဖြစ်လို့ delay ရှိမယ်မဟုတ်ရင် cache မှာရေးပြီး reponse လုပ်နောက်မှ interval နဲ့ database မှာသွားရေး။ ပထမကောင်ကို write-through လို့ခေါ်ပြီးနောက်ကောင်ကို write-back cache လို့ခေါ်တယ်။ နောက်ပြီး cache ကျော်ပြီး db မှာသွားရေးတာကိုက write-around လို့ခေါ်သေးတယ်။ သူက cache miss ဖြစ်နိုင်တယ်ဘာလို့လဲဆို cache ကိုနောက်မှပြန် update တာမို့။

System design မှာ optimize လုပ်တဲ့အခါတစ်နေရာထဲကိုပဲကွက်ပြီး optimize လို့မရဘူး။ A system is only as fast as its slowest bottleneck.
Database ကိုပဲ optimize ထားလဲ LB ပိုင်းကျန်ခဲ့ရင်အဲ့မှာလာပြီး bottleneck ဖြစ်မှာပဲ။

System design ကို post တစ်ခုနဲဘယ်လိုမှရေးလို့တော့မဖြစ်နိုင်ဘူး အခုပြောသွားတာတောင်အပေါ်ယံပဲရှိသေးတာ။ CAP theorem (Consistency, Availability, Partition Tolerance) နားလည်ဖို့ကျန်သေးတယ်။ ပြီးတော့ message queues တွေဘယ်နေရာမှာသုံးမှာလဲ။ Internal API calls တွေကို REST နဲ့ရေးဖို့ထက် message queue သုံးမှာလား နောက်ဘာလို့ message queue သုံးမှာလဲ။ Message queue က retry ကဘာလို့အသုံးတည့်တာလဲ။ ပြီးတော့ chat message လို real-time data ကိုဘယ်လို handle မလဲ။ အဲ့မှာ web-socket တစ်ခုပဲပြေးမြင်လို့မရဘူး။ Kafka သုံးပြီးဖြစ်ဖြစ်လုပ်တဲ့ Pub/Sub messaging လိုမျိုးတွေကျန်သေးတယ်။ SQL/NoSQL နဲ့ကဘာကွာတာလဲဘယ်ကောင်ကဘာအတွက်ပိုကောင်းတာလဲ။ နောက် Instagram က follower/following တွေမျိုးကို Neo4j လို graph database သုံးတာမျိုးတွေစသဖြင့် system design ကတော်တော်ပြောစရာများတယ်။

တစ်ခုနားလည်ရမှာကလူအယောက် ၁၀၀၀ သုံးတဲ့ application နဲ့ လူအယောက် 10 million သုံးတဲ့ app ကအပေါ်ယံတူတယ်ထင်ပေမယ့်တကယ်ကတော်တော်ကိုကွာတယ်။ ကျွန်တော်ကိုယ်တိုင်လဲလက်ရှိအလုပ်မှာ interview တာတွေရှိတယ်။ in-experience နဲ့ experience ကလုပ်သက်ဘယ်လောက်ကြာသလဲဘယ်နှနှစ်အလုပ်လုပ်တာရှိပြီးလဲဆိုတာ code quality အပြင်ခုနကလို system တစ်ခုခု design လုပ်ခိုင်းလိုက်ရင်လုပ်တာပေါ်မူတည်ပြီးတော်တော်တော့ experience ကပေါ်လွင်တယ်။

System design ပိုင်းကို interview အတွက် prepare ရင် Grokking The System Design Interview ဆိုတဲ့ course ကမဆိုးဘူးပြောလို့ရတယ်။ နောက်အောက်က post ကလဲ system design နဲ့ပတ်သက်ပြီး topic တစ်ခုချင်းစီကိုကောင်းကောင်းရှင်းပြပေးထားတယ်။
System Design Interview Questions – Concepts You Should Know.