Skip to main content

Model Artifact: Capstone Defense Packet

Scenario​

A Semester 10 learner prepares the final defense packet for a production-style inventory reservation service.

Completed learner-quality example​

Executive summary​

The capstone implements an inventory reservation service for flash-sale workloads. It exposes reservation APIs, enforces per-item consistency with database transactions, deploys through CI/CD, and includes dashboards, alerts, ADRs, and runbooks.

Problem and users​

Merchants need to prevent overselling during short demand spikes. Buyers need fast feedback that an item is reserved before payment. Operators need visibility into reservation failures, saturation, and recovery steps.

Architecture evidence​

  • Context diagram showing client, API, database, cache, and worker boundaries.
  • ADRs for transaction isolation, idempotency keys, and asynchronous expiration.
  • API contract with example successful, duplicate, expired, and insufficient-stock responses.

Engineering evidence​

  • Unit tests for reservation state transitions.
  • Integration tests for concurrent reservation attempts.
  • Load test showing p95 reserve latency under target at expected peak traffic.
  • CI pipeline requiring tests, lint, migration check, and container build.

Operations evidence​

  • Terraform plan for staging and production-like environments.
  • Dashboard for request rate, error rate, latency, database locks, and queue lag.
  • Runbook for high reservation failure rate.
  • Rollback plan for API deployment and database migration.

Security and risk evidence​

  • Threat model for authentication, abuse, replay, and data exposure.
  • Secrets stored in managed secret storage, not repository files.
  • Dependency scan reviewed before final defense.

Defense agenda​

  1. Five-minute product and architecture overview.
  2. Ten-minute live demo with normal and duplicate reservation paths.
  3. Five-minute failure injection: worker paused, alert and runbook used.
  4. Ten-minute questioning on tradeoffs, limitations, and next iteration.

Known limitations​

The service does not yet support cross-region active-active writes. The defense explains why single-region transactional correctness was chosen for this scope and what would need to change for multi-region inventory.

How to read this example​

  • Passing: Packages problem, architecture, implementation, operations, security, and demo plan.
  • Strong: Provides evidence for claims instead of relying on narrative confidence.
  • Portfolio-worthy: Acknowledges limitations and defends tradeoffs with a credible next-step path.