20 · Production engineering and architecture / LESSON 101 OF 102
Modular design, migrations, resilience, and release review
A backend is ready for review when another developer can operate it and verify its failure behavior.
Before this lesson: Events, async work, queues, and the outbox pattern
Understand the topic
Start with clear modules and dependency direction before splitting into network services. Microservices add deployment, observability, and consistency costs. Use timeouts, bounded retries with backoff, and circuit breaking only with a clear failure contract and idempotency policy.
Plan compatible schema rollouts using expand, migrate, and contract steps. Rehearse application rollback against the new schema and test database restore. Review access boundaries, load limits, recovery procedures, and API compatibility before treating a successful demo as an operational release.
EXAMPLE · SHELL
Release rehearsal commands
./mvnw clean verify
docker build -t task-api:review .
# Start with a disposable database and external runtime configuration.
# Apply migrations, run the API acceptance collection, then replace the app image.
# Restore a database backup into a second disposable instance and compare counts.What to expect
This is a rehearsal sequence. Supply your project’s container and backup commands in its runbook; do not run destructive experiments against production.
YOUR TURN
Put it into practice
- 01Run the capstone from a clean checkout using only its README.
- 02Rehearse a dependency outage, stale update, unauthorized request, application rollback, and backup restore.
- 03Verify: Another developer can reproduce setup, tests, failure diagnosis, and recovery without your private environment.
Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.
UNDER THE HOOD
Build the mental model
A backend is ready for review when another developer can operate it and verify its failure behavior.
- 01Start with clear modules and dependency direction before splitting into network services. Microservices add deployment, observability, and consistency costs. Use timeouts, bounded retries with backoff, and circuit breaking only with a clear failure contract and idempotency policy.
- 02Plan compatible schema rollouts using expand, migrate, and contract steps. Rehearse application rollback against the new schema and test database restore. Review access boundaries, load limits, recovery procedures, and API compatibility before treating a successful demo as an operational release.
- 03Trace the example: This is a rehearsal sequence. Supply your project’s container and backup commands in its runbook; do not run destructive experiments against production.
A mistake worth avoiding
Rolling back the application fails because a migration removed a required column.
DEBUGGING ROOM
Something broke. Where do you look?
Rolling back the application fails because a migration removed a required column.
Before revealing the diagnosis, write down your first investigation step.
CHECK YOUR UNDERSTANDING
Does splitting into microservices automatically make a small application more reliable?
BUILD IT YOURSELF
Run the capstone from a clean checkout using only its README.
- 1.Run the capstone from a clean checkout using only its README.
- 2.Rehearse a dependency outage, stale update, unauthorized request, application rollback, and backup restore.
- 3.Reproduce this failure, then repair it: Rolling back the application fails because a migration removed a required column.
Acceptance checklist
Lab completion is your self-report. Knowledge checks do not certify project quality.
RETRIEVE IT FROM MEMORY
Does splitting into microservices automatically make a small application more reliable?
Revisit this lesson in three days after a successful check or lab.
Ready for the next step?
Another developer can reproduce setup, tests, failure diagnosis, and recovery without your private environment.
Reading is separate from passing a knowledge check or completing a lab.