Project brief — globally available serverless multi-cloud platform

The Course 5 Capstone project synthesises every topic across the six modules into a single cohesive architecture: a globally available, serverless, multi-cloud scorecard platform. The platform serves IPL live match data to fans worldwide with sub-200ms response latency, automatic regional failover within 90 seconds, zero-downtime deployments, and a total infrastructure cost under $500 per month for 100 million monthly API calls. Building this platform requires every architectural skill developed in Modules 1 through 5.

The capstone is structured in three implementation milestones. Milestone 1 builds the AWS serverless backend: Lambda, API Gateway, and DynamoDB Global Tables in ap-south-1 as the primary region and ap-southeast-1 as the active-active secondary. Milestone 2 adds the Azure failback tier: Azure Functions and Azure Database for PostgreSQL in West Europe as a third-region warm standby, fronted by Azure Traffic Manager for global load balancing and failover. Milestone 3 produces the FinOps cost model, the DR runbook, and the Well-Architected review.

The finished capstone submission consists of three artefacts: a deployed architecture accessible via a live demo URL, a 12-month multi-cloud cost model in spreadsheet format, and a written Well-Architected review identifying the architecture’s top three High Risk Issues across the six pillars with proposed remediations. These three artefacts mirror the deliverables a Solutions Architect would produce for an enterprise client engagement, making the capstone a portfolio-ready project demonstrating end-to-end cloud architecture competency.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.