Lab: review MicroBank before Kubernetes

1. Establish the handoff

Use the MicroBank checkout and local transaction evidence from DevOps Foundations. You can keep containers stopped while you review the source and design. The reference revision below is the curriculum baseline, not an instruction to reset your working tree.

git rev-parse HEAD
git status --short

Create a design note under .local/advanced-design/. Record the actual revision and any local changes that affect behavior. If the Foundations journey is not yet passing, record that blocker; you can review the source now, but must resolve the runtime handoff before the Kubernetes deployment lab.

2. Trace one accepted deposit

Inspect the transaction controller/service, transaction model, outbox publisher, queue initialization, Ledger consumer/service, and Ledger entity in your checkout. Start with these reference sources↗.

Draw the path with named boundaries:

Caller
  -> Accounts API -> Accounts DB (transaction + outbox)
                         |
                    outbox publisher -> SNS -> SQS
                                                 |
                                           Ledger consumer
                                                 |
                                             Ledger DB

This is a deposit-flow review sketch, not a complete architecture or deployment manifest. Draw Ledger settlement publication separately and identify its ordering relative to the database commit. Add frontend/read paths only when you can point to their implementation. Do not draw an implemented settlement consumer, authorization policy, or cache based solely on a proposed design.

3. Write the design record

Use this outline in your own Markdown note:

## Scope and evidence
- Revision and local modifications:
- One user journey:
- Evidence already collected in Foundations:
- Unknowns and exclusions:

## Contracts and state ownership
- API acceptance and completion meanings:
- Authentication and authorization evidence:
- Idempotency key scope, payload rules, and retention:
- Database transaction boundaries and constraints:
- Message delivery, acknowledgement, and replay behavior:

## Capacity and reliability
- Workload assumptions, units, and evidence source:
- Limiting dependency and measurement needed:
- Deadline, retry budget, and overload response:
- User-facing indicator and proposed objective:
- Restore procedure, proposed RTO/RPO, and verification:

## Decision
- Options considered:
- Chosen next change and trade-off:
- Validation needed before adoption:
- Rollback/recovery procedure:

4. Walk a failure without claiming a test run

Choose one case: response lost after acceptance, repeated queue delivery, database commit failure after broker publication, or a slow Ledger causing backlog. Trace the exact ordering and durable records. State what is known from source and what needs a runtime experiment.

For example, if an outbox event is sent but its publication marker is not committed, the next publisher pass can send it again. A design response is durable idempotent consumption; validation must include the actual storage constraint, repeated processing, and concurrency. A sequential happy-path check does not establish all of these.

Use the algorithm toolkit only where it fits: summarize event occurrences, explore a declared dependency graph, or calculate a query window. Keep source evidence and synthetic inputs separate. This lab does not change MicroBank services or authorize fault injection.

5. Carry questions into the later modules

Checkpoint and revision

Finish with one traceable diagram, the Markdown design record, a failure timeline, and one prioritized improvement with an acceptance test. Label measurements, assumptions, proposals, and unresolved gaps. Keep production-readiness, restore, and throughput claims tied to results you have actually demonstrated.

Continue to Database foundations with PostgreSQL, then bring its schema inspection and recovery evidence into Kubernetes. Keep this design note and your Foundations evidence; later labs should refine them as new observations arrive.

Assess the design before continuing

A useful submission lets another reader follow one accepted operation without guessing where data commits. For each arrow, name the interface and possible failure; for each state store, name its owner. A diagram labelled only “microservices → cloud” cannot support the retry and restore questions.

Check your chosen failure against the source: if publication succeeds before its marker commits, duplicated publication is a possibility. Do not relabel this as a measured incident. Your next concrete task is the PostgreSQL fixture, which teaches the constraints, transactions, and restore vocabulary needed to inspect the real schema.

Sources

MicroBank reference revision↗, transactional outbox↗, retry with backoff↗, and user-oriented SLOs↗. These are original learning exercises; source inspection does not certify a deployed system.