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 anything with real logic,
@WebMvcTest/@DataJpaTestslice tests for controllers and repositories 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 PIT against your core business logic and fix at least one gap a surviving mutant reveals, rather than trusting line coverage alone.
- Week 12 observability — Spring Boot Actuator health checks wired to real dependency checks (not just "the app is up"), meaningful custom metrics beyond the defaults, structured JSON logs, and distributed tracing if the architecture genuinely has more than one service to trace across.
- 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 a look at whether virtual threads are worth enabling given the service's actual I/O profile.
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 — Kubernetes if the architecture warrants it, or a simpler managed platform if it doesn't; either is fine as long as it's a genuine, reachable deployment, not just "it runs on my machine."
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 Spring Boot 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.
Requirements:
- Complete the full testing pass from Section 1: unit, slice, and Testcontainers integration tests; a contract test if more than one service is involved; and at least one mutation-testing gap found and fixed.
- Wire up Actuator health checks against real dependencies, custom metrics, and structured logging; take a screenshot of a working dashboard showing real traffic.
- Build the multi-stage gated pipeline from Week 24, verify each gate fails correctly when deliberately broken, and deploy through it with a progressive rollout (canary or blue-green).
- Confirm a live, reachable endpoint, and run one real load test or fault-injection check (Weeks 22–23) against it, capturing the result.
- Write a README/architecture doc covering: a diagram of the service (and any other services it talks to), every architectural tradeoff from Week 25 and why it was made — including which advanced modules were deliberately left out — and what you'd change with more time or budget.
Not scope or technique count — a small service that's fully working, well-tested, and clearly explained reads as far more credible to anyone reviewing it (an employer, a collaborator, future-you) than an ambitious service that uses every pattern from the course but is only half-finished and untested.
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 — the same discipline behind writing a test's expectations before, not after, checking what the code currently does. A capstone with a scope document written first has a real definition of "done" to be judged against.
✓
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 GraphQL, Spring Batch, or a full Authorization Server 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 entities, 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 @RestController 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.