Choose one owner for each retry.

Draw the ownership boundary

An HTTP client, a queue, an SDK and a worker can each retry the same underlying action. If the client retries a request three times and the worker retries its own downstream action three times per request, the dependency may see nine attempts. An architecture diagram that shows only one arrow obscures this multiplication.

For each boundary write down: who initiates another attempt, which failures qualify, the attempt or time budget, and the identifier that remains stable. Keep transport request IDs for tracing while using a separate logical key for the business action. A network timeout often leaves the caller uncertain about whether the action happened.

Read the delivery mechanism first

Direct asynchronous Lambda invocations enter a service-managed event queue. Function errors and throttling/system errors can have different retry behavior. Review the source documentation for the actual settings, failure destinations and event age; do not transfer a generic retry number into every trigger.

With SQS, a poller obtains messages and invokes the function with a batch. Visibility and redrive settings govern reappearance and dead-letter behavior. If partial batch responses are configured, a worker can identify failed records instead of retrying successful ones as part of the same batch. Validate this with a deliberately mixed test batch in a controlled environment.

Make duplicate delivery observable and safe

A receipt should distinguish “already completed” from “freshly processed.” Consider a worker that sends a report to a third-party storage API and crashes before recording success. On redelivery, a simple local boolean may be false even though the remote object exists. Use a deterministic object key, downstream idempotency token or reconciliation lookup that can identify the previous effect.

Record enough state to describe started, completed, ambiguous and permanently rejected work. Retain the relevant deduplication state for a window matched to your actual redrive policy. Once the retention window expires, the system may no longer recognize an old manual replay; make that a conscious operational decision.

Practice stopping as well as retrying

Separate malformed inputs, permission failures and unavailable dependencies. Retrying the first two unchanged often creates load without progress. For temporary failures, use a bounded policy and appropriate backoff; coordinate it with provider retry behavior rather than adding competing loops.

An exhausted event is a result to investigate. Keep its original logical key, the failure category and a reference to redacted diagnostics. Test the replay procedure with a known repair and verify the final effect before replaying a group. Monitoring only function errors misses valid invocations that return a business-level rejection or suppress a duplicate.

Sources & next step

Use the primary documentation for your integration and configuration. Provider behavior can change. These guides do not inspect accounts or execute cloud requests.

Download this guide as Markdown

Try the workload lab