Project: Platform Architecture အပြည့်အစုံ ဒီဇိုင်းရေးဆွဲခြင်း

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

ဤ capstone project သည် course တစ်ခုလုံးရှိ lesson အများစုကို ဒီဇိုင်းတစ်ခုတည်းထဲ ပေါင်းစပ်ပေးသောကြောင့် နောက်ဆုံးတွင် ရှိနေခြင်းဖြစ်သည်။ requirement set ကို တမင်တကာ ပြည့်စုံစွာ ပေးထားသည်- fast global frontend, scalable backend API, managed database, user authentication, object storage, monitoring, ထို့နောက် rollback strategy။

Requirement	သက်ဆိုင်ရာ Lesson
Fast global frontend	modern-platform comparison ၏ edge-hosting tier
Scalable backend API	platform decision guide + platform-selection-lab project
Managed database	major-cloud comparison + database-platform lesson
Authentication	BaaS-vs-custom-backend project
Object storage	၎င်းကိုယ်ပိုင် dedicated platform category
Monitoring	observability-across-platforms lesson
Rollback strategy	rollback-strategies-deep-dive lesson

ဤနေရာတွင် specific vendor အမည် တောင်းဆိုသည်မရှိပြီး၊ တကယ်တမ်း deploy လုပ်ရန်လည်း တောင်းဆိုသည်မဟုတ်ပါ။ deliverable ကား category များဖြင့်သာ ဖော်ပြထားသော architecture အပြည့်အစုံဖြစ်ပြီး ဆက်စပ်ညီညွတ်သော diagram တစ်ခုတည်းထဲ ပေါင်းစည်းထားရမည်။

ဒါက Design ပါ၊ Deployment မဟုတ်ပါ

ဤ project သည် justify ထားသော architecture diagram တစ်ခုတွင် ရပ်တန့်ထားသည်— category များကို တကယ်တမ်း deploy လုပ်ခြင်းမှာ Cloud & Deployment ကိုယ်တိုင်၏ project များနှင့် AWS/Docker/CI-CD/Firebase course များ၏ တာဝန်ဖြစ်သည်။

text

FULL PLATFORM ARCHITECTURE
--------------------------
USERS
  |
  v
[ DNS / CDN edge layer ]
  |
  v
[ Frontend platform ]
  |
  v
[ Backend platform ] ---- [ Rollback strategy ]
  |
  +-----------+-----------+
  |           |           |
  v           v           v
[ Database ] [ Auth ]  [ Storage ]
  |           |           |
  +-----------+-----------+
              |
              v
     [ Observability ]

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

Requirement များကို စာရင်းပြုစုပါ

ခုနစ်ချက်လုံးကို ပေးထားသည့်အတိုင်း အတိအကျ ရေးချထားပါ။

တစ်ခုစီကို category နှင့် ကိုက်ညှိပါ

DNS/CDN, frontend, backend, database, auth, storage, observability တစ်ခုစီအတွက် earlier lesson ဆင်ခြင်တုံတရားကို အသုံးချပါ။

Diagram ကို စုစည်းတည်ဆောက်ပါ

user->DNS/CDN->frontend->backend->(database/auth/storage)->observability စီးဆင်းမှုကို တစ်ခုတည်းသော diagram ထဲ ဆွဲပါ။

Rollback strategy ကို ရွေးချယ်ပါ

စနစ်ခံနိုင်ရည်ရှိသော downtime ပမာဏနှင့် ကိုက်ညီသော rollback strategy ကို rollback-strategies-deep-dive lesson မှ ရွေးချယ်ပါ။

Run လုပ်ပြီး requirement နှစ်စုံနှင့် နှိုင်းယှဉ်ပါ

designPlatformArchitecture ကို requirement set နှစ်ခုအပေါ် run လုပ်ပြီး category များ တကယ်ပြောင်းလဲကြောင်း အတည်ပြုပါ။

Architecture အပြည့်အစုံသည် layer အလိုက် category ဆုံးဖြတ်ချက်များမှ စုစည်းတည်ဆောက်ထားခြင်းဖြစ်ပြီး vendor ရွေးချယ်မှုမဟုတ်
earlier lesson များ၏ ဆုံးဖြတ်ချက် framework များသည် စနစ်ကြီးတစ်ခု၏ layer တစ်ခုစီတွင် ထပ်မံ အသုံးဝင်သည်
Rollback strategy သည် architecture ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်ပြီး နောက်ဆက်တွဲ အချက်တစ်ခုမဟုတ်ပါ

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

javascript

function decideCompute(trafficPattern, needsLongRunningProcess) {
  if (needsLongRunningProcess) return "Container/VM-based PaaS (persistent compute)";
  if (trafficPattern === "unpredictable") return "Serverless functions / scale-to-zero platform";
  return "Managed PaaS with autoscaling (steady traffic)";
}

function decideAuth(teamSize, expectedComplexityGrowth) {
  if (expectedComplexityGrowth === "high" || teamSize === "large") {
    return "Custom auth on the backend (full control for complex rules)";
  }
  return "BaaS-provided auth (Supabase/Firebase-style, faster to ship)";
}

function decideRollback(rollbackPriority) {
  if (rollbackPriority === "high") return "Blue-green or canary deployment with instant rollback";
  if (rollbackPriority === "medium") return "Versioned releases with a documented manual rollback runbook";
  return "Redeploy-previous-commit rollback (accept brief downtime)";
}

function designPlatformArchitecture(requirements) {
  return {
    project: requirements.name,
    dnsCdn: "Global CDN/DNS edge layer in front of the frontend and backend",
    frontend: requirements.needsGlobalFrontend
      ? "Edge-deployed frontend hosting platform (static + SSR, global CDN built in)"
      : "Regional frontend hosting (single-region static or server-rendered)",
    backend: decideCompute(requirements.backendTrafficPattern, requirements.needsLongRunningProcess),
    database: requirements.needsDatabase
      ? "Managed database platform (kept provider-agnostic where practical)"
      : "No managed database needed",
    auth: requirements.needsAuth
      ? decideAuth(requirements.teamSize, requirements.expectedComplexityGrowth)
      : "No authentication needed",
    storage: requirements.needsFileUploads
      ? "Object storage category (S3-compatible) for user uploads"
      : "No object storage needed",
    observability: requirements.needsMonitoring
      ? "Third-party observability platform (logs, metrics, traces, alerting)"
      : "Basic platform-provided logs only",
    rollback: decideRollback(requirements.rollbackPriority)
  };
}

const productionSaas = {
  name: "Production SaaS Platform",
  needsGlobalFrontend: true,
  backendTrafficPattern: "steady",
  needsLongRunningProcess: true,
  needsDatabase: true,
  needsAuth: true,
  teamSize: "small",
  expectedComplexityGrowth: "medium",
  needsFileUploads: true,
  needsMonitoring: true,
  rollbackPriority: "high"
};

const personalBlog = {
  name: "Personal Blog with Comments",
  needsGlobalFrontend: true,
  backendTrafficPattern: "unpredictable",
  needsLongRunningProcess: false,
  needsDatabase: true,
  needsAuth: false,
  teamSize: "solo",
  expectedComplexityGrowth: "low",
  needsFileUploads: false,
  needsMonitoring: false,
  rollbackPriority: "low"
};

console.log(JSON.stringify(designPlatformArchitecture(productionSaas), null, 2));
console.log(JSON.stringify(designPlatformArchitecture(personalBlog), null, 2));

You should see

production requirement set အပေါ် designPlatformArchitecture ကို run လုပ်လျှင် backend 'Container/VM-based PaaS (persistent compute)', auth 'BaaS-provided auth', rollback 'Blue-green or canary deployment with instant rollback' ကို print ထုတ်သည်။ app သေးငယ်တစ်ခု (personal blog) ၏ requirement အပေါ် ထပ်မံ run လုပ်လျှင် backend 'Serverless functions / scale-to-zero platform', auth 'No authentication needed', rollback 'Redeploy-previous-commit rollback' ကို print ထုတ်ပြီး architecture သည် requirement မတူလျှင် တကယ်ပြောင်းလဲကြောင်း အတည်ပြုသည်။

၅ မိနစ် စမ်းကြည့်

production requirement set ၏ backendTrafficPattern ကို 'steady' အစား 'unpredictable' သို့ ပြောင်းပါ၊ needsLongRunningProcess ကိုမူ true အတိုင်း ထားပါ။ designPlatformArchitecture ကို ပြန် run လုပ်ပြီး traffic pattern ပြောင်းသွားသော်လည်း backend category မပြောင်းလဲရသည့်အကြောင်းရင်းကို စာကြောင်းတစ်ကြောင်းဖြင့် ရှင်းပြပါ။

သတိလေးတစ်ချက်

database, auth, storage category များကို သီးခြားစီ ဒီဇိုင်းရေးဆွဲပြီး layer တစ်ခု၏ ဆုံးဖြတ်ချက်က အခြားတစ်ခုကို ကန့်သတ်နိုင်ခြင်းရှိမရှိ (ဥပမာ BaaS auth ရွေးချယ်မှုက ထို BaaS ၏ database ကိုပါ ရွေးချယ်စေမည့်ဖိအားပေးမှု) ကို မစစ်ဆေးခြင်း။

rollback strategy ကို layer သီးခြားတစ်ခုတည်း၏ နောက်ဆက်တွဲအဖြစ် ရှုမြင်ပြီး စနစ်တစ်ခုချင်းစီ ခံနိုင်ရည်ရှိသော downtime ပမာဏနှင့် ကိုက်ညီစေရန် မလုပ်ဆောင်ခြင်း။

Martin Fowler - BlueGreenDeployment — Cloud Providers & Platforms