Tratamento de erros, repetições e filas de mensagens não entregues

When a function throws or times out, the platform treats it as a failed invocation. How that failure is handled depends on how the function was invoked.

• Synchronous: error returns to the caller
• Asynchronous: platform retries automatically
• Stream/poll: behavior depends on the source

For synchronous calls (like an API request) the error is returned immediately to the caller. The caller, such as API Gateway, decides how to map it to an HTTP status.

For asynchronous invocations the platform automatically retries failed events a couple of times with delay before giving up. Your code must be safe to run more than once.

Because retries can re-run an event, functions should be idempotent: processing the same event twice produces the same result without duplicate side effects.

Catch expected errors and respond gracefully; let truly unexpected errors bubble up so the platform can retry or record them.

A dead-letter queue (DLQ) captures events that still fail after all retries, so they are not lost. You can inspect and reprocess them later.

• Attach an SQS queue or SNS topic as the DLQ
• Failed events land there with metadata

You point the function at a DLQ target. After exhausting retries, the platform delivers the failed event there instead of dropping it.

Beyond DLQs, destinations route the result of async invocations on success or failure to another service, with richer context than a DLQ provides.

For stream sources (like a queue or stream), a failing batch can block progress. Configure batch bisection or a maximum retry age so a single poison message does not stall the whole stream.

A timeout is a kind of failure: the function did not finish in time. Set timeouts realistically and instrument long operations so you can tell timeouts apart from thrown errors.

Log errors with context, emit metrics for failure counts, and alarm on DLQ depth. A growing DLQ is an early signal that something is systematically broken.

You learned robust Lambda error handling: how errors propagate per invocation type, why idempotency matters with retries, how to use try/except wisely, and how dead-letter queues and destinations capture failures so events are never silently lost.