1. Testing, Observability & Performance Pass
Apply Weeks 8, 12, 22, and 23 in full, not as an afterthought bolted on at the end:
- A full Week 8-style test suite — unit tests for pure business logic,
TestClientand dependency-override tests for routes in isolation, and Testcontainers integration tests that exercise the full stack against a real database (and a real broker, if Week 25's architecture added one). - Contract tests (Week 22) — if the capstone involves more than one service, a Pact contract test between them, verified on both the consumer and provider side.
- A mutation testing pass (Week 22) — run
mutmutagainst your core business logic and fix at least one gap a surviving mutant reveals, rather than trusting line coverage alone. - Week 12 observability — structured JSON logs with a request ID, a
/healthzendpoint wired to real dependency checks (not just "the process is alive"), and meaningfulprometheus-clientmetrics beyond the defaults. - A performance sanity check (Week 23) — connection pool sizing that's been deliberately set, an N+1 check (Weeks 5 and 15) on every collection-returning endpoint, and profiling data (Week 23) backing any performance claim in your write-up rather than a guess.
None of this is optional polish. A service with no Testcontainers coverage hasn't actually proven it talks to a real database correctly, a service with a surviving mutant in its core logic has a test suite that looks thorough but isn't, and a service with no health checks or metrics can't prove it's healthy in production even if it happens to be — this pass exists to close exactly those gaps.
2. Deployment & Progressive Rollout
A correct service nobody else can reach is far less useful as a portfolio piece than a modest one that's actually live, shipped the way Week 24 taught. Containerize and deploy it through a real gated pipeline:
- A multi-stage pipeline (Week 24) — separate test, build-and-scan, and deploy stages, each gating the next, verified by deliberately breaking a test and a security scan and confirming the deploy stage never runs.
- A progressive rollout (Week 24) — at minimum a canary with a small initial replica count and version-tagged metrics to watch before scaling it up; blue-green is an equally valid choice if you can justify why an instant-cutover model fits your capstone better.
- A real deployment target — a free-tier host on Fly.io, Render, or Railway is enough, with a genuine reachable URL backed by a real managed database instead of
localhostor SQLite.
Getting a container running is a demo. Getting it there through a tested, mutation-checked, security-scanned, gated pipeline, with a progressive rollout a reviewer can watch happen and dashboards showing the canary's real metrics, is the difference a hiring manager is actually screening for.
3. The Capstone Project
Test, observe, deploy and defend a complete FastAPI service
Take Week 25's implementation fully through Sections 1–2 above: tested and observable, shipped through a real gated, progressive pipeline, and defended in writing. This is a definition-of-done checklist, not a suggestion list — treat every item as required for the capstone to count as complete.
Definition of done:
- A documented resource model and API contract exist before implementation, with an explicit "out of scope" note for anything you deliberately excluded.
- Database migrations exist for the full schema, and a seed script can populate a fresh database with realistic sample data.
- Every write endpoint requires authentication, and authorization is enforced by ownership or membership checks — not just "is any user logged in."
- A layered test suite exists: unit, integration, and API-level tests, a contract test if more than one service is involved, and at least one mutation-testing gap found and fixed.
- The service emits structured logs with a request ID, exposes a
/healthzendpoint checking real dependencies, and reports meaningful Prometheus metrics. - A multi-stage, gated pipeline builds and scans the image in CI, and deploys it through a progressive rollout (canary or blue-green) you can point to and explain.
- The service is deployed to a real, reachable URL, backed by a real managed database rather than an in-memory or SQLite fallback.
- A README documents setup, environment variables, how to run the test suite, the deployed URL with example requests, and every architectural tradeoff — including which advanced modules from Weeks 15–24 were deliberately left out and why.
A service that's deployed early and grown incrementally almost always ends the week in better shape than one where deployment was saved for "once everything's ready," because deployment surfaces environment and configuration problems you want to find on day one, not day six of a two-week capstone.
4. Final Checklist
Before calling the capstone — and the course — done, confirm each of these honestly:
✓
Was the scope and API surface written down before any code was written?
Was the scope and API surface written down before any code was written?
If the domain model and endpoint list were written after the service already existed, they describe what got built rather than what was planned. A capstone with a scope document written first has a real definition of "done" to be judged against, rather than one that shifts to match whatever happened to get built.
✓
Can every architectural choice — including which advanced modules from Weeks 15–24 were deliberately left out — be justified, rather than just having used every technique from the course?
Can every architectural choice — including which advanced modules from Weeks 15–24 were deliberately left out — be justified, rather than just having used every technique from the course?
Every service split, saga, message broker, and cache layer is added complexity and failure surface to maintain. A capstone that can justify each choice crisply — including why gRPC, GraphQL, or Airflow weren't needed here — reads as far stronger engineering judgment than one that reached for everything the course covered regardless of fit.
✓
Does the full test suite pass, including Testcontainers integration tests, and does it survive mutation testing rather than just achieving high line coverage?
Does the full test suite pass, including Testcontainers integration tests, and does it survive mutation testing rather than just achieving high line coverage?
Unit and slice tests alone can pass against mocks while the real integration between your models, queries, and an actual database is still broken, and high coverage can hide assertions too weak to notice a real bug. Testcontainers tests plus at least one mutation-testing gap found and fixed are what prove the suite works against something close to production and actually catches bugs, not just executes code.
✓
Does the pipeline fail loudly and stop before deploying if a test fails or a critical vulnerability is found — and did the rollout actually happen progressively, not all at once?
Does the pipeline fail loudly and stop before deploying if a test fails or a critical vulnerability is found — and did the rollout actually happen progressively, not all at once?
A pipeline where deploy can run even after a test or the scan fails isn't actually gating anything — verify this by deliberately breaking each one. A rollout that flips 100% of traffic to a new version in one step, even if a canary Deployment technically exists in the manifests, hasn't actually exercised the progressive delivery behavior the capstone is supposed to demonstrate — the ramp-up needs to have genuinely happened, watched, and documented.
✓
Is the service actually deployed and reachable, with a write-up someone could evaluate without reading the source?
Is the service actually deployed and reachable, with a write-up someone could evaluate without reading the source?
A service that only runs on your own machine, with your own local database and config, isn't actually finished — deployment isn't optional polish tacked on at the end; it's the proof the service is real. Paired with a write-up covering the architecture, the tradeoffs, and what you'd change, a live endpoint is the actual deliverable a reader will judge the whole project by.
From a first typed function in Week 1 to a tested, mutation-checked, security-scanned, progressively-deployed production service — with the architectural judgment to know which advanced techniques your project actually needed and which it didn't — every module in between exists somewhere in what you just shipped. Congratulations on reaching the capstone.