Batch Processing
The batch processing utility handles partial failures when processing batches from Amazon SQS, Amazon Kinesis Data Streams, and Amazon DynamoDB Streams.
stateDiagram-v2
direction LR
BatchSource: Amazon SQS <br/><br/> Amazon Kinesis Data Streams <br/><br/> Amazon DynamoDB Streams <br/><br/>
LambdaInit: Lambda invocation
BatchProcessor: Batch Processor
RecordHandler: Record Handler function
YourLogic: Your logic to process each batch item
LambdaResponse: Lambda response
BatchSource --> LambdaInit
LambdaInit --> BatchProcessor
BatchProcessor --> RecordHandler
state BatchProcessor {
[*] --> RecordHandler: Your function
RecordHandler --> YourLogic
}
RecordHandler --> BatchProcessor: Collect results
BatchProcessor --> LambdaResponse: Report items that failed processing
Key features¶
- Reports batch item failures to reduce number of retries for a record upon errors
- Simple interface to process each batch record
- Bring your own batch processor
- Parallel processing
Background¶
When using SQS, Kinesis Data Streams, or DynamoDB Streams as a Lambda event source, your Lambda functions are triggered with a batch of messages.
If your function fails to process any message from the batch, the entire batch returns to your queue or stream. This same batch is then retried until either condition happens first: a) your Lambda function returns a successful response, b) record reaches maximum retry attempts, or c) when records expire.
journey
section Conditions
Successful response: 5: Success
Maximum retries: 3: Failure
Records expired: 1: Failure
This behavior changes when you enable Report Batch Item Failures feature in your Lambda function event source configuration:
- SQS queues. Only messages reported as failure will return to the queue for a retry, while successful ones will be deleted.
- Kinesis data streams and DynamoDB streams. Single reported failure will use its sequence number as the stream checkpoint. Multiple reported failures will use the lowest sequence number as checkpoint.
Warning: This utility lowers the chance of processing records more than once; it does not guarantee it
We recommend implementing processing logic in an idempotent manner wherever possible.
You can find more details on how Lambda works with either SQS, Kinesis, or DynamoDB in the AWS Documentation.
Installation¶
You should install with NuGet:
1 |
|
Or via the .NET Core command line interface:
1 |
|
Getting started¶
For this feature to work, you need to (1) configure your Lambda function event source to use ReportBatchItemFailures
, and (2) return a specific response to report which records failed to be processed.
You use your preferred deployment framework to set the correct configuration while this utility handles the correct response to be returned.
Batch processing can be configured with the settings bellow:
Setting | Description | Environment variable | Default |
---|---|---|---|
Error Handling Policy | The error handling policy to apply during batch processing. | POWERTOOLS_BATCH_ERROR_HANDLING_POLICY |
DeriveFromEvent |
Parallel Enabled | Controls if parallel processing of batch items is enabled. | POWERTOOLS_BATCH_PARALLEL_ENABLED |
false |
Max Degree of Parallelism | The maximum degree of parallelism to apply if parallel processing is enabled. | POWERTOOLS_BATCH_MAX_DEGREE_OF_PARALLELISM |
1 |
Throw on Full Batch Failure | Controls if a BatchProcessingException is thrown on full batch failure. |
POWERTOOLS_BATCH_THROW_ON_FULL_BATCH_FAILURE |
true |
Required resources¶
The remaining sections of the documentation will rely on these samples. For completeness, this demonstrates IAM permissions and Dead Letter Queue where batch records will be sent after 2 retries were attempted.
You do not need any additional IAM permissions to use this utility, except for what each event source requires.
template.yaml | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 |
|
template.yaml | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 |
|
template.yaml | |
---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 |
|
Processing messages from SQS¶
Using Handler decorator¶
Processing batches from SQS using Lambda handler decorator works in three stages:
- Decorate your handler with
BatchProcessor
attribute - Create a class that implements
ISqsRecordHandler
interface and the HandleAsync method. - Pass the type of that class to
RecordHandler
property of theBatchProcessor
attribute - Return
BatchItemFailuresResponse
from Lambda handler usingSqsBatchProcessor.Result.BatchItemFailuresResponse
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
- Step 1. Creates a class that implements ISqsRecordHandler interface and the HandleAsync method.
- Step 2. You can have custom logic inside the record handler and throw exceptions that will cause this message to fail
- Step 3. RecordHandlerResult can return empty (None) or some data.
- Step 4. Lambda function returns the Partial batch response
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|
The second record failed to be processed, therefore the processor added its message ID in the response.
1 2 3 4 5 6 7 8 9 10 |
|
FIFO queues¶
When using SQS FIFO queues, we will stop processing messages after the first failure, and return all failed and unprocessed messages in batchItemFailures
.
This helps preserve the ordering of messages in your queue. Powertools automatically detects a FIFO queue.
Processing messages from Kinesis¶
Processing batches from Kinesis using Lambda handler decorator works in three stages:
- Decorate your handler with
BatchProcessor
attribute - Create a class that implements
IKinesisEventRecordHandler
interface and the HandleAsync method. - Pass the type of that class to
RecordHandler
property of theBatchProcessor
attribute - Return
BatchItemFailuresResponse
from Lambda handler usingKinesisEventBatchProcessor.Result.BatchItemFailuresResponse
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
- Step 1. Creates a class that implements the IKinesisEventRecordHandler interface and the HandleAsync method.
- Step 2. You can have custom logic inside the record handler and throw exceptions that will cause this message to fail
- Step 3. RecordHandlerResult can return empty (None) or some data.
- Step 4. Lambda function returns the Partial batch response
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|
The second record failed to be processed, therefore the processor added its message ID in the response.
1 2 3 4 5 6 7 8 9 10 |
|
Processing messages from DynamoDB¶
Processing batches from DynamoDB Streams using Lambda handler decorator works in three stages:
- Decorate your handler with
BatchProcessor
attribute - Create a class that implements
IDynamoDbStreamRecordHandler
and the HandleAsync method. - Pass the type of that class to
RecordHandler
property of theBatchProcessor
attribute - Return
BatchItemFailuresResponse
from Lambda handler usingDynamoDbStreamBatchProcessor.Result.BatchItemFailuresResponse
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
- Step 1. Creates a class that implements the IDynamoDbStreamRecordHandler and the HandleAsync method.
- Step 2. You can have custom logic inside the record handler and throw exceptions that will cause this message to fail
- Step 3. RecordHandlerResult can return empty (None) or some data.
- Step 4. Lambda function returns the Partial batch response
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
|
The second record failed to be processed, therefore the processor added its message ID in the response.
1 2 3 4 5 6 7 |
|
Error handling¶
By default, we catch any exception raised by your custom record handler HandleAsync method (ISqsRecordHandler, IKinesisEventRecordHandler, IDynamoDbStreamRecordHandler). This allows us to (1) continue processing the batch, (2) collect each batch item that failed processing, and (3) return the appropriate response correctly without failing your Lambda function execution.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|
The second record failed to be processed, therefore the processor added its message ID in the response.
1 2 3 4 5 6 7 8 9 10 |
|
Error Handling Policy¶
You can specify the error handling policy applied during batch processing.
ErrorHandlingPolicy
is used to control the error handling policy of the batch item processing.
With a value of DeriveFromEvent
(default), the specific BatchProcessor, determines the policy based on the incoming event.
For example, the SqsBatchProcessor
looks at the EventSourceArn to determine if the ErrorHandlingPolicy should be StopOnFirstBatchItemFailure
(for FIFO queues) or ContinueOnBatchItemFailure
(for standard queues).
For StopOnFirstBatchItemFailure
the batch processor stops processing and marks any remaining records as batch item failures.
For ContinueOnBatchItemFailure
the batch processor continues processing batch items regardless of item failures.
Policy | Description |
---|---|
DeriveFromEvent | Auto-derive the policy based on the event. |
ContinueOnBatchItemFailure | Continue processing regardless of whether other batch items fails during processing. |
StopOnFirstBatchItemFailure | Stop processing other batch items after the first batch item has failed processing. This is useful to preserve ordered processing of events. |
Note
When using StopOnFirstBatchItemFailure and parallel processing is enabled, all batch items already scheduled to be processed, will be allowed to complete before the batch processing stops.
Therefore, if order is important, it is recommended to use sequential (non-parallel) processing together with this value."
To change the default error handling policy, you can set the POWERTOOLS_BATCH_ERROR_HANDLING_POLICY
Environment Variable.
Another approach is to decorate the handler and use one of the policies in the ErrorHandlingPolicy
Enum property of the BatchProcessor
attribute
1 2 3 4 5 6 |
|
Partial failure mechanics¶
All records in the batch will be passed to this handler for processing, even if exceptions are thrown - Here's the behaviour after completing the batch:
- All records successfully processed. We will return an empty list of item failures
{'batchItemFailures': []}
. - Partial success with some exceptions. We will return a list of all item IDs/sequence numbers that failed processing.
- All records failed to be processed. By defaullt, we will throw a
BatchProcessingException
with a list of all exceptions raised during processing to reflect the failure in your operational metrics. However, in some scenarios, this might not be desired. See Working with full batch failures for more information.
The following sequence diagrams explain how each Batch processor behaves under different scenarios.
SQS Standard¶
Read more about Batch Failure Reporting feature in AWS Lambda.
Sequence diagram to explain how BatchProcessor
works with SQS Standard queues.
sequenceDiagram
autonumber
participant SQS queue
participant Lambda service
participant Lambda function
Lambda service->>SQS queue: Poll
Lambda service->>Lambda function: Invoke (batch event)
Lambda function->>Lambda service: Report some failed messages
activate SQS queue
Lambda service->>SQS queue: Delete successful messages
SQS queue-->>SQS queue: Failed messages return
Note over SQS queue,Lambda service: Process repeat
deactivate SQS queue
SQS mechanism with Batch Item Failures
SQS FIFO¶
Read more about Batch Failure Reporting feature in AWS Lambda.
Sequence diagram to explain how SqsFifoPartialProcessor
works with SQS FIFO queues.
sequenceDiagram
autonumber
participant SQS queue
participant Lambda service
participant Lambda function
Lambda service->>SQS queue: Poll
Lambda service->>Lambda function: Invoke (batch event)
activate Lambda function
Lambda function-->Lambda function: Process 2 out of 10 batch items
Lambda function--xLambda function: Fail on 3rd batch item
Lambda function->>Lambda service: Report 3rd batch item and unprocessed messages as failure
deactivate Lambda function
activate SQS queue
Lambda service->>SQS queue: Delete successful messages (1-2)
SQS queue-->>SQS queue: Failed messages return (3-10)
deactivate SQS queue
SQS FIFO mechanism with Batch Item Failures
Kinesis and DynamoDB Streams¶
Read more about Batch Failure Reporting feature.
Sequence diagram to explain how BatchProcessor
works with both Kinesis Data Streams and DynamoDB Streams.
For brevity, we will use Streams
to refer to either services. For theory on stream checkpoints, see this blog post
sequenceDiagram
autonumber
participant Streams
participant Lambda service
participant Lambda function
Lambda service->>Streams: Poll latest records
Lambda service->>Lambda function: Invoke (batch event)
activate Lambda function
Lambda function-->Lambda function: Process 2 out of 10 batch items
Lambda function--xLambda function: Fail on 3rd batch item
Lambda function-->Lambda function: Continue processing batch items (4-10)
Lambda function->>Lambda service: Report batch item as failure (3)
deactivate Lambda function
activate Streams
Lambda service->>Streams: Checkpoints to sequence number from 3rd batch item
Lambda service->>Streams: Poll records starting from updated checkpoint
deactivate Streams
Kinesis and DynamoDB streams mechanism with single batch item failure
The behavior changes slightly when there are multiple item failures. Stream checkpoint is updated to the lowest sequence number reported.
Note that the batch item sequence number could be different from batch item number in the illustration.
sequenceDiagram
autonumber
participant Streams
participant Lambda service
participant Lambda function
Lambda service->>Streams: Poll latest records
Lambda service->>Lambda function: Invoke (batch event)
activate Lambda function
Lambda function-->Lambda function: Process 2 out of 10 batch items
Lambda function--xLambda function: Fail on 3-5 batch items
Lambda function-->Lambda function: Continue processing batch items (6-10)
Lambda function->>Lambda service: Report batch items as failure (3-5)
deactivate Lambda function
activate Streams
Lambda service->>Streams: Checkpoints to lowest sequence number
Lambda service->>Streams: Poll records starting from updated checkpoint
deactivate Streams
Kinesis and DynamoDB streams mechanism with multiple batch item failures
Advanced¶
Using utility outside handler and IoC¶
You can use Batch processing without using the decorator.
Calling the ProcessAsync
method on the Instance of the static BatchProcessor (SqsBatchProcessor
, DynamoDbStreamBatchProcessor
, KinesisEventBatchProcessor
)
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
To make the handler testable you can use Dependency Injection to resolve the BatchProcessor (SqsBatchProcessor
, DynamoDbStreamBatchProcessor
, KinesisEventBatchProcessor
) instance and then call the ProcessAsync
method.
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
Processing messages in parallel¶
You can set the POWERTOOLS_BATCH_PARALLEL_ENABLED
Environment Variable to true
or set the property BatchParallelProcessingEnabled
on the Lambda decorator to process messages concurrently.
You can also set POWERTOOLS_BATCH_MAX_DEGREE_OF_PARALLELISM
Environment Variable to the number of parallelism you which.
Note
MaxDegreeOfParallelism is used to control the parallelism of the batch item processing.
With a value of 1, the processing is done sequentially (default). Sequential processing is recommended when preserving order is important - i.e. with SQS FIFIO queues.
With a value > 1, the processing is done in parallel. Doing parallel processing can enable processing to complete faster, i.e., when processing does downstream service calls.
With a value of -1, the parallelism is automatically configured to be the vCPU count of the Lambda function. Internally, the Batch Processing Utility utilizes Parallel.ForEachAsync Method and the ParallelOptions.MaxDegreeOfParallelism Property to enable this functionality.
When is this useful?
Your use case might be able to process multiple records at the same time without conflicting with one another.
For example, imagine you need to process multiple loyalty points and incrementally save in a database. While you await the database to confirm your records are saved, you could start processing another request concurrently.
The reason this is not the default behaviour is that not all use cases can handle concurrency safely (e.g., loyalty points must be updated in order).
1 2 3 4 5 |
|
Working with full batch failures¶
By default, the BatchProcessor
will throw a BatchProcessingException
if all records in the batch fail to process. We do this to reflect the failure in your operational metrics.
When working with functions that handle batches with a small number of records, or when you use errors as a flow control mechanism, this behavior might not be desirable as your function might generate an unnaturally high number of errors. When this happens, the Lambda service will scale down the concurrency of your function, potentially impacting performance.
For these scenarios, you can set POWERTOOLS_BATCH_THROW_ON_FULL_BATCH_FAILURE = false
, or the equivalent on either the BatchProcessor
decorator or on the ProcessingOptions
object. See examples below.
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 7 8 9 10 11 |
|
Extending BatchProcessor¶
You might want to bring custom logic to the existing BatchProcessor
to slightly override how we handle successes and failures.
For these scenarios, you can create a class that inherits from BatchProcessor
(SqsBatchProcessor
, DynamoDbStreamBatchProcessor
, KinesisEventBatchProcessor
) and quickly override ProcessAsync
and HandleRecordFailureAsync
methods:
ProcessAsync()
– Keeps track of successful batch recordsHandleRecordFailureAsync()
– Keeps track of failed batch records
Example
Let's suppose you'd like to add a metric named BatchRecordFailures
for each batch record that failed processing. And also override the default error handling policy to stop on first item failure.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 |
|
Testing your code¶
As there is no external calls, you can unit test your code with BatchProcessor
quite easily.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
1 2 3 4 5 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|