Learning bite
Design data recovery before cutover
Define the recovered dataset and verification before choosing a backup procedure.
AWS
Predict before you try
Does a successful Ledger-only restore establish full-system recovery?
Try it: Work through the MicroBank example →On this page
The operating question
MicroBank’s Accounts database, Ledger database, and in-flight events describe related work. A snapshot or dump of one database does not establish a consistent recovery of the entire application. Define the failure scenario, acceptable data loss, recovery time, and how writes and queued messages are handled. RDS supports backup and restore operations, but the application still needs a verified recovery procedure for its intended scope.
Work through the MicroBank example
Write a recovery case for one database first: identify the backup, restore into a separate destination, compare known records, and document what remains outside the test. Design the wider Accounts/Ledger/message cutover separately. Use the existing local PostgreSQL lab before a cloud rehearsal.
A small recovery record keeps the proof narrow:
| Stage | Ledger-only rehearsal | What it does not establish |
|---|---|---|
| Select | Identify the backup, source revision, and known saved case | That every application component shares that recovery point |
| Restore | Use a separate database destination | That production cutover has happened |
| Compare | Read the matching entry and expected balance | That Accounts and in-flight messages are consistent |
| Decide | Record the verified scope and missing wider checks | That fresh writes can safely resume everywhere |
Recovery point objective is the acceptable data-loss window; recovery time objective is the acceptable recovery duration. Set requirements first, then measure a rehearsal against them.
Keep the selected source revision and distinguish an illustrative design from actual environment evidence. The teaching reference is MicroBank f75da68 from the implementation guide. Inspect newer application branches before carrying version-specific findings forward.
Compare your reasoning
Does a successful Ledger-only restore establish full-system recovery? No. It verifies the declared Ledger scope; Accounts and queued events require their own consistency and cutover evidence.
Checkpoint
Save your diagram or decision record, its assumptions, and the next missing verification. No cloud account or provisioning is required for this design bite. Any later cloud run needs its own approved sandbox, scoped identity, cost boundaries, and cleanup evidence.
Read further
Prove what you learned
Inspect the result
Save the component/owner decision, a denied or failed path, and the missing verification.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Change one design requirement and revise only the affected decisions; state the trade-off.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Work through the MicroBank example”.
- Save the component/owner decision, a denied or failed path, and the missing verification.
- Explain the transfer challenge and retain the same verification question.
Hint
Separate runtime, identity, network, data, messaging and recovery ownership.
Answer guide: compare after predicting
No. It verifies the declared Ledger scope; Accounts and queued events require their own consistency and cutover evidence.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall the source-derived MicroBank component map and cloud service responsibility model. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.