Learning bite
Keep the messaging contract explicit
A deployment target must preserve or deliberately adapt the application’s messaging API contract.
AWS
Predict before you try
Would raw-message delivery be a harmless infrastructure-only change in the pinned baseline?
Try it: Work through the MicroBank example →On this page
The operating question
The pinned MicroBank publisher calls SNS, and Ledger consumes SQS messages with the expected SNS envelope. Moving those processes to a new compute platform does not replace the messaging APIs. A target can retain the AWS dependency as a documented design, or implement a different adapter with its own compatibility and failure tests. Local emulation checks the selected operations in the emulator, not every property of the real managed service.
Work through the MicroBank example
Trace the requested-event route from topic to subscription, queue policy, queue, and consumer parser. Write the expected envelope and identify the evidence needed before replacing the backend. Preserve one owner for resource creation and lifecycle.
Keep both delivery format and ownership visible:
| Handoff | What must agree | Failure to look for |
|---|---|---|
| Publisher → SNS topic | Selected topic and permitted publish operation | Wrong target or denied publish |
| Topic → queue subscription | Intended subscription and queue access policy | Message never reaches the intended queue |
| Queue → Ledger parser | SNS envelope expected by the pinned consumer | Raw delivery or a different body shape is rejected |
| Ledger → saved result | Case identity, matching persisted entry, and balance | Message receipt without the required application result |
This is a design trace. A supported envelope in Floci is useful local evidence; it does not establish every AWS failure or delivery property.
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
Would raw-message delivery be a harmless infrastructure-only change in the pinned baseline? No. It changes the envelope that Ledger’s consumer expects.
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 changes the envelope that Ledger’s consumer expects.
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.