နားလည်ထားရမယ့် အချက်
ဒီ capstone project က tool အသစ်တစ်ခုကို မိတ်ဆက်တာမဟုတ်ပါဘူး — deployment decision guide ရဲ့ worked example တစ်ခုပါ — finished diagram တစ်ခုကနေ စမယ့်အစား ဘယ် component တွေက load-bearing လဲ၊ ဘာကြောင့်လဲဆိုတာ ကိုယ်တိုင် ဆင်ခြင်ရပါတယ်။
Scenario က ဒီလိုပါ — subscription SaaS အသေးလေးတစ်ခုမှာ file upload၊ background email ပို့ခြင်း၊ ခန့်မှန်းမရတဲ့ traffic spike (product launch, newsletter mention) ရှိပါတယ်။ အောက်က component တစ်ခုချင်းစီက အဲဒီ sentence ထဲက requirement တိကျတစ်ခုကြောင့်ပဲ နေရာရသွားတာပါ။
| Component | ဘာကြောင့်ပါလဲ |
|---|---|
| DNS | Entry point; domain ကို server တိုက်ရိုက်အစား CDN ဆီ resolve လုပ်ပေးတယ်။ |
| CDN | static asset တွေကို cache လုပ်ပြီး user နဲ့နီးတဲ့နေရာမှာ TLS terminate လုပ်တယ်၊ origin load လျော့ချတယ်။ |
| Load balancer | traffic-spike requirement ကြောင့် ရှိတယ် — request တွေကို app instance တွေကို ဖြန့်ပေးတယ်။ |
| App instances | stateless compute; load balancer က traffic များလာတာ တွေ့ရင် horizontally scale ထွက်နိုင်တယ်။ |
| Database | SaaS တိုင်း subscription နဲ့ user data အတွက် durable storage လိုတယ် — baseline အနေနဲ့ မပါမဖြစ်။ |
| Cache | traffic-spike requirement ကြောင့် ရှိတယ် — repeated read တွေကို ကာကွယ်ပေးလို့ database မထိခိုက်။ |
| Queue | background-email requirement ကြောင့် ရှိတယ် — slow work ကို request path ထဲကနေ ဖယ်ထုတ်ပေးတယ်။ |
| Object storage | file-upload requirement ကြောင့် ရှိတယ် — disposable app instance အပြင်ဘက်မှာ file တွေအတွက် durable နေရာ။ |
| Monitoring | ဒီ scale မှာ non-negotiable — အပေါ်က component တစ်ခုချင်းစီ healthy ဖြစ်မဖြစ် ပြသမယ့် နေရာတစ်ခု။ |
Monitoring က အားလုံးကို ခြုံပတ်ထားပါတယ်၊ ဘာဖြစ်လို့လဲဆိုတော့ ဒီလောက် component နက်တဲ့ production system တစ်ခုက component တစ်ခုချင်းစီ healthy ဖြစ်မဖြစ် ပြသပေးမယ့် နေရာတစ်ခုတည်း လိုအပ်လို့ပါ။
PRODUCTION SaaS ARCHITECTURE
----------------------------
[USERS]
|
v
[DNS] (yourapp.com resolves to the CDN)
|
v
[CDN] (caches static assets, terminates TLS at the edge)
|
v
[LOAD BALANCER] (spreads requests across app instances)
|
+-------------+-------------+
v v v
[APP #1] [APP #2] [APP N]
| | |
+-------------+-------------+
|
+------------+------------+------------+
v v v v
[DATABASE] [CACHE] [QUEUE] [OBJECT STORAGE]
(billing, (Redis: (email (uploaded files,
user data) hot reads) jobs) e.g. S3 bucket)
| | | |
+------------+------------+------------+
|
v
[MONITORING]
(metrics, logs, alerts for
every component above)လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Baseline: DNS + CDN
scenario details ဘာပဲဖြစ်ဖြစ် production app တိုင်း ဒါတွေလိုတယ်။
Load balancer + app instances ထပ်ထည့်ပါ
traffic-spike requirement ကြောင့် — instance တစ်ခုတည်းက spike ကို မခံနိုင်ဘူး။
Database + cache ထပ်ထည့်ပါ
database က subscription/user data အတွက်; cache က spike အချိန် repeated-read pressure ကနေ ကာကွယ်ပေး။
Background work ရှိမှသာ queue ထည့်ပါ
scope ထဲက background-email requirement ကနေပဲ justify လုပ်တယ်။
Upload ရှိမှသာ object storage ထည့်ပါ
scope ထဲက file-upload requirement ကနေပဲ justify လုပ်တယ်။
Component အားလုံးအတွက် monitoring နဲ့ ပြီးပါစေ
Uptime/latency, query performance, queue depth, storage and cache metrics — ဒီ scale မှာ non-negotiable။
ဘာကို မထည့်ခဲ့ဘူးဆိုတာ သတိပြုပါ — ဘာမှ "best practice" ဆိုတဲ့ abstract concept ကြောင့် ဒီမှာမရှိပါဘူး။ piece တစ်ခုချင်းစီက scenario ထဲက line တစ်ကြောင်းဆီ ချိတ်ဆက်နိုင်ပါတယ်။
အတူတူ စမ်းရေးကြည့်မယ်
function designArchitecture({ hasFileUploads, hasBackgroundEmail, expectsTrafficSpikes }) {
const components = [
{
name: "Load balancer + multiple app instances",
needed: expectsTrafficSpikes,
reason: "distributes traffic across replicas so a spike doesn't overwhelm a single server",
},
{
name: "CDN in front of the app",
needed: expectsTrafficSpikes,
reason: "caches static assets at edge locations, cutting origin load during a spike",
},
{
name: "Object storage (e.g. S3-compatible bucket)",
needed: hasFileUploads,
reason: "uploaded files need durable storage outside the app servers, which are disposable",
},
{
name: "Background job queue + worker process",
needed: hasBackgroundEmail,
reason: "sending email during the request would block the response; a queue defers it",
},
{
name: "Cache layer (e.g. Redis)",
needed: expectsTrafficSpikes,
reason: "absorbs repeated reads so the database isn't hit for every request during a spike",
},
{
name: "Managed production database",
needed: true,
reason: "every SaaS app needs durable, backed-up storage for user and subscription data",
},
{
name: "Monitoring and alerting",
needed: true,
reason: "you need to know about failures before your users report them, spike or not",
},
];
const chosen = components.filter((c) => c.needed);
console.log(`Scenario: uploads=${hasFileUploads}, email=${hasBackgroundEmail}, spikes=${expectsTrafficSpikes}`);
console.log(`Components needed: ${chosen.length} of ${components.length}\n`);
for (const c of chosen) {
console.log(`- ${c.name}\n reason: ${c.reason}`);
}
return chosen.map((c) => c.name);
}
designArchitecture({ hasFileUploads: true, hasBackgroundEmail: true, expectsTrafficSpikes: true });Scenario ရဲ့ flag သုံးခုစလုံး true ဖြစ်နေလို့ component ၇ ခုစလုံး needed ဖြစ်ပြီး reason တစ်ခုချင်းစီနဲ့အတူ print ထုတ်ပါတယ်:
Scenario: uploads=true, email=true, spikes=true
Components needed: 7 of 7
- Load balancer + multiple app instances
reason: distributes traffic across replicas so a spike doesn't overwhelm a single server
- CDN in front of the app
reason: caches static assets at edge locations, cutting origin load during a spike
- Object storage (e.g. S3-compatible bucket)
reason: uploaded files need durable storage outside the app servers, which are disposable
- Background job queue + worker process
reason: sending email during the request would block the response; a queue defers it
- Cache layer (e.g. Redis)
reason: absorbs repeated reads so the database isn't hit for every request during a spike
- Managed production database
reason: every SaaS app needs durable, backed-up storage for user and subscription data
- Monitoring and alerting
reason: you need to know about failures before your users report them, spike or not၅ မိနစ် စမ်းကြည့်
designArchitecture function ကို hasFileUploads: false, hasBackgroundEmail: false, expectsTrafficSpikes: false နဲ့ ပြန် run ကြည့်ပါ — traffic တည်ငြိမ်၊ ခန့်မှန်းရလွယ်တဲ့ internal tool အသေးလေးတစ်ခုပေါ့။ ဘယ် component တွေ ပျောက်သွားလဲ၊ ရလာတဲ့ list က architecture အစစ်အနေနဲ့ အဓိပ္ပါယ်ရှိနေသေးလား?
သတိလေးတစ်ချက်
traffic နည်းတဲ့ app အသေးလေးတစ်ခုမှာ diagram အပြည့်ထဲက component အားလုံးကို 'ရှိရင်ကောင်းမလား' ဆိုပြီး ထည့်လိုက်တာ — ဘယ်သူမှ မလိုအပ်သေးတဲ့ queue ဒါမှမဟုတ် cache layer သီးခြားတစ်ခုက cost နဲ့ operational surface ကို ထပ်တိုးစေတာ။
monitoring ကို production incident ပထမဆုံးအကြိမ် ဖြစ်ပြီးမှ ထည့်တာ၊ day one ကတည်းက basic uptime နဲ့ error alert ချိတ်ဆက်မထားခဲ့တာ။
AWS Well-Architected Framework — Cloud & Deployment