Capstone Overview and Architecture Planning

This capstone brings together everything from Modules 1 through 12 into one project: designing and deploying a small cloud application for a fictional online learning platform, in the spirit of QuarryDev itself but not QuarryDev's actual production infrastructure — nothing in this module connects to, modifies, or describes any real deployed system. It's a learning architecture, built from a realistic scenario.

The scenario: learners browse a catalogue of courses, sign in, work through lesson content, have their progress saved, and — on completing a course — receive a certificate. Somewhere behind that experience: static assets need serving, an API needs to handle requests, data needs to persist reliably, some work should happen in the background rather than block the learner, the whole thing needs to be secured, observed, deployable from code, and kept within a sane budget.

None of the individual AWS services in that list are new. What's new in this module is combining them into one coherent design and being able to explain, for every piece, why it's there — not just that it's there.

Before naming a single AWS service, a capstone worth its name separates two different kinds of requirement.

Functional requirements describe what the application must do: learners can browse courses, sign in, view lesson content, have progress recorded, and receive a certificate on completion.

Non-functional requirements describe how well the application must do it: how many concurrent learners it should comfortably support, how quickly pages should load, what happens if a component fails, how learner data is protected, who can access what, and what the whole thing is allowed to cost to run.

This distinction matters because it changes what "the right answer" even means. A functional requirement ("learners must be able to view a lesson") can usually be satisfied by more than one architecture. It's the non-functional requirements — availability, security, cost, operability — that actually separate one design from another. Requirements come before AWS service selection, in that order, every time.

Every architecture decision in this module is recorded the same way, using a Project Decision Record: five short fields that force the reasoning to actually happen instead of being assumed.

• Requirement — the specific functional or non-functional requirement this decision answers.
• Decision — what was chosen.
• Reason — why this choice satisfies the requirement.
• Alternative — what else was genuinely considered.
• Trade-off — what the chosen option gives up compared to the alternative.

Worked example, used throughout this module: a learner completing a course should receive a certificate, but generating it (rendering a document, possibly emailing it) shouldn't make the learner wait on that work before their "course complete" screen appears.

• Requirement: certificate generation must not block the learner's completion request.
• Decision: hand certificate generation off to an SQS queue processed by a background worker.
• Reason: this decouples the request path from a slower, non-critical background task.
• Alternative: generate the certificate synchronously, inline in the same request.
• Trade-off: the async design adds real complexity — retries, the possibility of duplicate processing, and needing to monitor for a growing backlog or a worker that stops consuming messages — in exchange for a request path that stays fast regardless of how long certificate generation takes.

A strong capstone submission fills in a record like this for every major decision. "I used DynamoDB because it scales" is not a Project Decision Record — it has no stated requirement, no alternative, and no trade-off.

Reading the diagram left to right: a learner's browser reaches an Amazon CloudFront distribution, which serves the static frontend from an S3 bucket (Lesson 2) and routes API calls to API Gateway, which invokes Lambda functions that read and write DynamoDB (Lessons 3 and 4). Cross-cutting concerns — IAM roles, CloudWatch monitoring, CloudTrail auditing, and a CloudFormation template that can reproduce the whole thing — apply across every layer rather than living in one box (Lessons 5, 6, and 7).

This is presented as one coherent, defensible design for this specific scenario — it is deliberately not presented as the only correct AWS architecture. A different, equally reasonable submission might choose EC2-hosted compute instead of Lambda, or a relational database instead of DynamoDB, if that submission's stated requirements genuinely justify it. What's being graded across this module is the reasoning — does the design satisfy the stated requirements, and can every decision be explained — not whether it matches this exact diagram.