Project: Design a Full Platform Architecture

Build the mental model

This capstone pulls together nearly every lesson in the course into one design, which is why it comes last. The requirement set is deliberately full: a fast global frontend, a scalable backend API, a managed database, user authentication, object storage for uploads, monitoring, and a rollback strategy.

Requirement	Which earlier lesson it revisits
Fast global frontend	Modern-platform comparison's 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	Its own dedicated platform category
Monitoring	Observability-across-platforms lesson
Rollback strategy	Rollback-strategies-deep-dive lesson

Nothing here asks for a specific vendor name, and nothing here asks you to actually deploy anything. The deliverable is a complete architecture expressed entirely in categories, assembled into one coherent diagram.

This is design, not deployment

This project stops at a justified architecture diagram -- actually deploying any of these categories is what Cloud & Deployment's own projects and the AWS/Docker/CI-CD/Firebase courses are for.

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 ]

Connect it to a real scenario

List the requirements

Write down all seven requirements exactly as given, before touching any code.

Map each to a category

Use the earlier lessons' reasoning for DNS/CDN, frontend, backend, database, auth, storage, and observability.

Assemble the diagram

Draw users -> DNS/CDN -> frontend -> backend -> (database / auth / storage) -> observability as one diagram.

Pick a rollback strategy

Match a rollback strategy from the rollback-strategies-deep-dive lesson to how much downtime the system can tolerate.

Run it against two requirement sets

Run designPlatformArchitecture against both requirement sets and confirm the categories genuinely change.

A full architecture is assembled from category decisions, not vendor picks, made layer by layer
The same decision frameworks from earlier lessons apply again at each layer of a bigger system
Rollback strategy is part of the architecture, not a separate afterthought

Try the working example

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

Running designPlatformArchitecture against the production requirement set prints backend 'Container/VM-based PaaS (persistent compute)', auth 'BaaS-provided auth', and rollback 'Blue-green or canary deployment with instant rollback'. Running it again against the smaller personal-blog requirements prints backend 'Serverless functions / scale-to-zero platform', auth 'No authentication needed', and rollback 'Redeploy-previous-commit rollback (accept brief downtime)' -- confirming the architecture genuinely changes with different needs.

5-minute try-it

Change the production requirement set so backendTrafficPattern is 'unpredictable' instead of 'steady' while needsLongRunningProcess stays true, run designPlatformArchitecture again, and explain in one sentence why the backend category does not change even though the traffic pattern did.

One important caution

Designing the database, auth, and storage categories in isolation instead of checking whether decisions in one layer constrain another (e.g. a BaaS auth choice nudging you toward that BaaS's own database too).

Treating rollback strategy as an afterthought tacked onto the end instead of a decision that should match how much downtime the specific system can tolerate.

Martin Fowler - BlueGreenDeployment — Cloud Providers & Platforms