Home labs & practical projects
Make an event consumer tolerate duplicate messages
A project to do with your own tools, with guidance on what to create and capture.
For existing holders and historical learning. Check the current credential before starting exam preparation.
What you could create
An order-processing function receives the same message twice after a retry. Each order must create a single business result, and failures must be visible.
| Evidence | What to capture |
|---|---|
| Consumer code and input fixtures | Show the inputs, scope and decisions behind this record. Repeating an order does not repeat the business action. |
| Test results for duplicates, retries and invalid input | Include the evidence supporting your conclusion. A failed message remains discoverable with its reason. |
What you'll need
Cloud sandbox
Use a test queue, a small function and a disposable record store. Prepare synthetic order IDs, one invalid payload and one deliberately repeated message.
Project record
Keep the working files for consumer code and input fixtures and record assumptions as you go.
Current reference material
Use the linked provider resources to verify the features, access terms and version relevant to your project.
Access & cost
A cloud account may incur charges. Check current service prices and quotas before creating resources; a budget alert is not a spending cap.
Use a separate learning account or subscription and synthetic data. Keep credentials and administrative endpoints private.
Suggested milestones
- 1
Plan and investigate
Implement an idempotency check tied to the business operation.
- 2
Develop your approach
Separate transient failures from invalid input and define a dead-letter path.
- 3
Verify and explain
Emit structured logs and run normal, duplicate and failing inputs.
Useful resources
Use these resources to deepen your understanding and check key details.
A useful starting point
Use a test queue, a small function and a disposable record store. Prepare synthetic order IDs, one invalid payload and one deliberately repeated message.
What a good result looks like
- Repeating an order does not repeat the business action.
- A failed message remains discoverable with its reason.
- Logs let another developer trace one order without exposing secrets.
Finish the project
Remove the exercise resources, including retained storage, snapshots and public IPs. Check the billing view for anything still running.
Independent home-project guidance, not an official vendor lab or a claim of complete exam coverage. Use your own tools and label the work accurately.