Thuta Learning
Cloud & Deployment
ProjectsDevOps & Toolsbeginner

Project: Production SaaS Architecture တစ်ခု ဒီဇိုင်းဆွဲခြင်း

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • Project: Production SaaS Architecture တစ်ခု ဒီဇိုင်းဆွဲခြင်း concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram ကို ဖတ်ပြီး architecture ထဲမှာ request/data ဘယ်လိုစီးဆင်းသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် project အတွက် ဘယ်လို ဆုံးဖြတ်သင့်သလဲ ရှင်းပြနိုင်ရန်

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

ဒီ 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ဘာကြောင့်ပါလဲ
DNSEntry point; domain ကို server တိုက်ရိုက်အစား CDN ဆီ resolve လုပ်ပေးတယ်။
CDNstatic asset တွေကို cache လုပ်ပြီး user နဲ့နီးတဲ့နေရာမှာ TLS terminate လုပ်တယ်၊ origin load လျော့ချတယ်။
Load balancertraffic-spike requirement ကြောင့် ရှိတယ် — request တွေကို app instance တွေကို ဖြန့်ပေးတယ်။
App instancesstateless compute; load balancer က traffic များလာတာ တွေ့ရင် horizontally scale ထွက်နိုင်တယ်။
DatabaseSaaS တိုင်း subscription နဲ့ user data အတွက် durable storage လိုတယ် — baseline အနေနဲ့ မပါမဖြစ်။
Cachetraffic-spike requirement ကြောင့် ရှိတယ် — repeated read တွေကို ကာကွယ်ပေးလို့ database မထိခိုက်။
Queuebackground-email requirement ကြောင့် ရှိတယ် — slow work ကို request path ထဲကနေ ဖယ်ထုတ်ပေးတယ်။
Object storagefile-upload requirement ကြောင့် ရှိတယ် — disposable app instance အပြင်ဘက်မှာ file တွေအတွက် durable နေရာ။
Monitoringဒီ scale မှာ non-negotiable — အပေါ်က component တစ်ခုချင်းစီ healthy ဖြစ်မဖြစ် ပြသမယ့် နေရာတစ်ခု။

Monitoring က အားလုံးကို ခြုံပတ်ထားပါတယ်၊ ဘာဖြစ်လို့လဲဆိုတော့ ဒီလောက် component နက်တဲ့ production system တစ်ခုက component တစ်ခုချင်းစီ healthy ဖြစ်မဖြစ် ပြသပေးမယ့် နေရာတစ်ခုတည်း လိုအပ်လို့ပါ။

text
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 တစ်ကြောင်းဆီ ချိတ်ဆက်နိုင်ပါတယ်။

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

javascript
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 });
You should see
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 FrameworkCloud & Deployment

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • traffic နည်းတဲ့ app အသေးလေးတစ်ခုမှာ diagram အပြည့်ထဲက component အားလုံးကို 'ရှိရင်ကောင်းမလား' ဆိုပြီး ထည့်လိုက်တာ — ဘယ်သူမှ မလိုအပ်သေးတဲ့ queue ဒါမှမဟုတ် cache layer သီးခြားတစ်ခုက cost နဲ့ operational surface ကို ထပ်တိုးစေတာ။
  • monitoring ကို production incident ပထမဆုံးအကြိမ် ဖြစ်ပြီးမှ ထည့်တာ၊ day one ကတည်းက basic uptime နဲ့ error alert ချိတ်ဆက်မထားခဲ့တာ။
  • Localhost မှာ အလုပ်လုပ်တာနဲ့ Production မှာ အလိုအလျောက်အလုပ်လုပ်မယ်လို့ မယူဆပါနှင့် — environment, network, database, security ကွာခြားချက်တွေ ရှိနိုင်ပါတယ်။

လေ့ကျင့်ခန်း

designArchitecture function ကို hasFileUploads: false, hasBackgroundEmail: false, expectsTrafficSpikes: false နဲ့ ပြန် run ကြည့်ပါ — traffic တည်ငြိမ်၊ ခန့်မှန်းရလွယ်တဲ့ internal tool အသေးလေးတစ်ခုပေါ့။ ဘယ် component တွေ ပျောက်သွားလဲ၊ ရလာတဲ့ list က architecture အစစ်အနေနဲ့ အဓိပ္ပါယ်ရှိနေသေးလား?

You'll know it worked when: 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

Project: Production SaaS Architecture တစ်ခု ဒီဇိုင်းဆွဲခြင်း | Thuta Learning