Production service project

Build one small service throughout the curriculum. A task tracker, bookmark manager, expense ledger, or inventory API is enough—the domain is less important than completing the engineering loop.

Constraints

• one application and one relational database;
• one repository and one deployment pipeline;
• no microservices, queue, cache, orchestrator, or cloud-specific abstraction until a measured requirement needs it;
• every added component must solve a documented problem.

Milestones

1. Local application

Create, read, update, and delete records through a command-line interface. Validate input, persist data, and test the important behavior.

Evidence: automated checks and setup instructions work on a clean checkout.

2. HTTP API

Expose the same behavior through HTTP. Define resource names, status codes, validation errors, pagination, and idempotency where needed.

Evidence: executable API examples cover both success and failure.

3. Relational database

Add schema migrations, constraints, transactions, and indexes. Record why each index exists.

Evidence: query plans and tests demonstrate constraints, transaction rollback, and conflicting updates.

4. Security boundary

Add authentication and resource-level authorization. Keep secrets outside source control and log security-relevant actions without logging credentials.

Evidence: tests prove that users cannot access or modify another user's data.

5. Repeatable delivery

Build a versioned artifact in CI, package that exact artifact in a container, and lock the resolved build and runtime inputs. Record source revision, dependency lock, checks, and artifact digests; claim bit-for-bit reproducibility only if repeated clean builds demonstrate it.

Evidence: a clean environment can produce, install, and run the documented version, and the release is traceable to its source and resolved dependencies.

6. Operability

Add health checks, structured logs, request metrics, latency and error indicators, dashboards, and actionable alerts.

Evidence: inject a failure and use telemetry to locate it.

7. Performance

Define a workload and latency target, establish a baseline, profile it, change one bottleneck, and compare results using the same test.

Evidence: retain measurements and explain uncertainty instead of reporting only the best run.

8. Distribution—only if justified

Choose one concrete pressure, such as a slow background operation. Add a queue or split a component only if the simpler system cannot meet the requirement.

Evidence: document duplicates, retries, ordering, partial failure, recovery, and the extra operational cost.

Final review

The project is complete when someone else can operate it from the documentation and you can explain:

• the path of a request through the system;
• the most important data and trust boundaries;
• what fails first as load grows;
• how failure is detected and recovered;
• which complexity you deliberately did not add.