Guided architecture tour · 6–8 min
Give a failed function another chance — Lambda and Retries
Plan safe retries for a function that receives events in the background.
This tour teaches architecture decisions. Its services are not provisioned in the emulator.
Your goal
Plan safe retries for a function that receives events in the background.
Why this matters
A temporary error should not lose an order or charge twice. You will distinguish background calls, make repeats safe, and save final failures for review.
Words you will use
Asynchronous means the caller does not wait for the function result. A retry repeats an attempt. A failure destination receives details when processing cannot finish.
How to proceed
Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.
1. Know who waits
An app sends an event for background processing and receives confirmation that it was accepted. The function has not finished yet. Choose what that confirmation proves.
Does accepted mean the job succeeded?
No; it means the event was accepted for later work.
For asynchronous invocation, acceptance and successful processing are separate. Lambda can retry certain failures. Direct calls and event-source mappings have different retry behavior.
You know to inspect processing results after acceptance.
Asynchronous invoke → accepted → later processing result2. Make another attempt safe
The function may receive the same order event more than once. It sends a paid order to shipping. Choose a way to avoid repeating an irreversible action.
What should the function use?
A stable order ID and a saved record of completed work.
Safe repeats are called idempotency. Use the same work ID to detect a completed action and return its result. Design the check and update so two attempts cannot both do the action.
A repeated event can reuse a completed result.
Order ID → atomic work check → perform safely → record result3. Keep the failures you cannot fix
An event keeps failing even after the configured attempts or age limit. You want a record to inspect and replay after a repair. Choose the next destination.
What belongs in the error plan?
A configured failure destination and a monitored recovery process.
For asynchronous calls, configure retry and event-age settings and an appropriate failure destination. Watch failures and decide how to repair and replay them safely.
The team can find and investigate events that never finished.
Retry/age limits → failure destination → investigation → safe replayPractice, then check your understanding
In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.
Read the official AWS documentation for service behavior and production details.