Invocação assíncrona do Lambda

When you invoke an AWS Lambda function asynchronously, you don't wait for the function's response. It's a "fire and forget" model.

• The caller sends the event and doesn't wait for the result.
• Lambda handles the queuing and execution in the background.
• This pattern is perfect for event-driven architectures where immediate feedback isn't required.

Here's the typical flow for an asynchronous Lambda invocation:

• An event source (like S3, SNS, or a direct invocation) sends an event.
• Lambda places this event into an internal queue.
• Lambda then invokes your function from this queue.
• The event source receives an immediate success response, even if the function hasn't started processing yet.

One of the key benefits of asynchronous invocation is built-in fault tolerance. If your function encounters an unhandled error or times out during processing:

• Lambda automatically retries the invocation.
• By default, it attempts up to two more retries (total of three attempts).
• These retries occur with exponential backoff, meaning increasing delays between attempts.

You have control over how Lambda handles failures for asynchronous invocations:

• You can configure the number of retry attempts (from 0 to 2).
• You can also set a Maximum Event Age, which is the longest time Lambda retains an event in its internal queue for processing.
• These settings can be adjusted in the Lambda console or through Infrastructure as Code (e.g., AWS SAM, CloudFormation).

What if your function fails after all retry attempts? By default, the event is dropped. This can lead to data loss.

A Dead-Letter Queue (DLQ) is a powerful feature that captures events that couldn't be processed successfully after all retries. It allows you to:

• Inspect and debug the failed events.
• Reprocess them later once the issue is resolved.
• Prevent critical data from being lost.

You can configure an Amazon SQS queue or an Amazon SNS topic as your Lambda function's DLQ:

• SQS Queue: Ideal for storing individual failed events for later batch processing or manual inspection.
• SNS Topic: Useful for sending notifications about failed events to multiple subscribers (e.g., email, other Lambda functions).

You specify the ARN (Amazon Resource Name) of your chosen DLQ resource in your Lambda function's configuration.

Concurrency refers to the number of requests your Lambda function is processing at any given time. Lambda automatically scales up to handle incoming events.

However, uncontrolled scaling can sometimes be problematic:

• Overloading downstream services (e.g., databases, APIs).
• Incurring unexpected costs.

AWS provides tools to manage concurrency: Reserved Concurrency and Provisioned Concurrency.

Reserved concurrency allows you to set a maximum number of concurrent executions for a specific Lambda function.

• It guarantees that your function always has that amount of capacity available.
• It prevents a single function from consuming all the available concurrency in your AWS account.
• If invocations exceed the reserved limit, they are throttled (rejected).

Provisioned concurrency pre-initializes a specified number of execution environments for your function.

• This significantly reduces cold starts, which are delays that occur when Lambda needs to set up a new execution environment.
• It's ideal for latency-sensitive applications like APIs where consistent, low-latency responses are crucial.
• You pay for provisioned concurrency even when the function isn't actively invoked.

Here's a simple Python Lambda function that simulates a failure based on event data. If configured with a DLQ, failed events would be sent there.

The if __name__ == "__main__": block demonstrates how to test it locally.

Consider an asynchronous Lambda function configured with a Dead-Letter Queue (DLQ). If the function fails on its initial invocation and then again on its first retry, what is the default behavior?

We explored asynchronous Lambda invocation, a "fire and forget" model ideal for event-driven architectures.

• Learned about default retry behavior and how to customize it.
• Understood Dead-Letter Queues (DLQs) for capturing and managing failed events, preventing data loss.
• Finally, we covered concurrency controls: Reserved Concurrency to limit max executions and Provisioned Concurrency to reduce cold starts.