Error Handling and Retry Mechanisms in AWS Lambda

Example Answer

I would identify the invocation mode before describing retries. For asynchronous invocation, Lambda retries a function error two additional times by default. Throttling and system errors use a different queue retry policy, with retries for up to six hours by default. Synchronous callers and event-source mappings have different behavior; there is no single retry rule for every Lambda trigger. I would make side effects idempotent, configure event age and failure handling where supported, and monitor discarded or repeatedly failing work. A dead-letter queue is a recovery path, not a guarantee that every event succeeds.

Failure example

A payment handler completes the external charge, then times out before recording success. A retry must not create a second charge. Use a stable event or business-operation identifier and a durable idempotency record or downstream idempotency key.

For Lambda's async queue, configure the appropriate failure destination or dead-letter queue and verify that delivery permissions work. For SQS, its queue redrive/DLQ policy is a separate mechanism. Test duplicates, exhausted retries, event expiration, and failure-destination delivery problems.

Practice follow-up

How would you replay failed events without repeating side effects that already completed?

Sources

Lambda async error handling; Lambda with SQS error handling.