Your Lambda Function Might Execute Twice. Deal With It!
Tired of your Lambda functions triggering twice? Let's see why it happens and how to keep your functions working and idempotent.
Join the DZone community and get the full member experience.
Join For FreeAre you confused when scheduled Lambdas execute twice, SNS messages trigger an invocation three times, your handmade S3 inventory is out of date because events occurred twice? Bad news: Sooner or later, your Lambda function will be invoked multiple times. You have to deal with it! The reasons are retries on errors and event sources that guarantee at-least-once delivery (e.g., CloudWatch Events, SNS, …).
How do you know that your Lambda function is broken (or not idempotent)? If your function is given the same input (AKA event) multiple times, the function MUST produce the same result. If your function produces different results with the same input, the implementation is not idempotent, and you are in big trouble.
You may ask yourself how to fix it. Let’s work with a concrete example. Imagine a Lambda function to ensure that a user can only make a specific number request per day. A request could be an upload to an S3 bucket, sending a message, whatever. In other words, the Lambda function implements rate limiting. To do so, you need to store some state. A good place to store the state is DynamoDB. Luckily, DynamoDB offers many features to fix your problem.
1. Iteration: The Not Idempotent Implementation
The first iteration provides the most simple implementation. But also a broken implementation.
The input event looks like this:
{
"user": "u1"
}
The function uses a DynamoDB table ratelimit
with the primary key id
(partition key). The id consists of the user and the current date (yyyy-mm-dd). Additionally, a calls
attribute of type number is used to track the number of calls.
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB({
apiVersion: '2012-08-10'
});
const limit = 8;
exports.handler = (event, context, cb) => {
const date = new Date().toISOString().slice(0, 10);
const id = `iteration1:${event.user}:${date}`;
dynamodb.updateItem({
TableName: `ratelimit`,
Key: {
id: {
S: id
},
},
UpdateExpression: 'ADD calls :one',
ExpressionAttributeValues: {
':one': {
N: '1'
}
},
ReturnValues: 'ALL_NEW'
}, function(err, data) {
if (err) {
cb(err);
} else {
const calls = parseInt(data.Attributes.calls.N, 10);
cb(null, {
limited: calls > limit
});
}
});
};
The implementation is not idempotent. The calls
attribute is incremented even if the invocation is just a retry. The implementation would limit too early in this case. Let’s fix that!
2. Iteration: The Mostly Idempotent Implementation
Let’s try to fix the first iteration. Add a request id to the event.
The input event looks like this:
{
"user": "u1",
"request": "r1"
}
All event sources provide some unique id that you can use as the request id. Some examples:
- Kinesis:
Records[].eventID
- SNS:
Records[].Sns.MessageId
- API Gateway:
requestContext.requestId
- Scheduled CloudWatch Event:
id
The function uses the same DynamoDB table from the first iteration. Instead of the calls
attribute, you use a requests
attribute of type string set.
The requests
attribute keeps track of all request ids that were already counts by the rate limiter. This way, you avoid to count the same request twice. DynamoDB also ensures that the requests
set is limited to a certain amount of request ids.
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB({
apiVersion: '2012-08-10'
});
const limit = 8;
exports.handler = (event, context, cb) => {
const date = new Date().toISOString().slice(0, 10);
const id = `iteration2:${event.user}:${date}`;
dynamodb.updateItem({
TableName: `ratelimit`,
Key: {
id: {
S: id
},
},
UpdateExpression: 'ADD requests :requests',
ConditionExpression: 'attribute_not_exists (requests) OR contains(requests, :request) OR size(requests) < :limit',
ExpressionAttributeValues: {
':request': {
S: event.request
},
':requests': {
SS: [event.request]
},
':limit': {
N: limit.toString()
}
}
}, function(err) {
if (err) {
if (err.code === 'ConditionalCheckFailedException') {
cb(null, {
limited: true
});
} else {
cb(err);
}
} else {
cb(null, {
limited: false
});
}
});
};
You can invoke this function as often as you like, as long as the input stays the same, the result is the same.
Wait, no. The date (yyyy-mm-dd) is used as part of the key. So if the current date changes to the next day, the result will be different.
3. Iteration: The Idempotent Implementation
Let’s fix that as well! The date has to be part of the input event as well. I added a timestamp but you could choose whatever format you like.
The input event looks like this:
{
"user": "u1",
"request": "r1",
"timestamp": 1510067704370
}
Some event sources provide a date value out of the box. Some examples:
- Kinesis: not supported but a workaround is possible: put the timestamp in the record data
- SNS:
Records[].Sns.Timestamp
- API Gateway: not supported and a workaround is problematic because you would rely on the client’s time
- Scheduled CloudWatch Event:
time
The function uses the same DynamoDB table from the first iteration. You can use the implementation of the second iteration. But replace the way the date
variable is generated:
const date = new Date(event.timestamp).toISOString().slice(0, 10);
That’s it. Idempotent rate limiting is implemented.
Summary: Request ids as a Savior
Use request identifiers to implement idempotent Lambda functions that do not break if a function invocation needs to be retried. Make sure to pass the original request id to all subsequent calls. The original request id is generated as early as possible in the chain. If possible on the client side. Avoid generating your own ids.
Use the original request id as the identity to guarantee idempotency:
- In DynamoDB, use it as a primary key together with a
ConditionExpression
orUpdateExpression SET if_not_exists(att, :val)
. - In Step Functions, use it as the execution name.
- For other services like Kinesis and SQS, put the original request id in the payload. The consumer can then use the original request id again.
You are now equipped to implement idempotent Lambda functions using DynamoDB. If you use any other data store, think carefully about idempotency!
Implementation Notes
The implementation does not work well with large limits (> 5000) because the requests set will grow with each request added. Sooner or later you will hit the 400 KB limitation of a DynamoDB item.
You could circumvent the limitation by working with smaller timespans (e.g., yyyy-mm-dd-hh or yyyy-mm-dd-hh-mm) which also leads to a lower limit but assumes a more or less even distribution of request during the day.
If you need a big limit, store each request as a separate item in DynamoDB and sum them asynchronously by using a DynamoDB stream on the table. Keep the current state about if a user is limited in a separate DynamoDB table. This is not an exact rate limiter, but with large limits, you could tolerate that users can make slightly more requests that allowed.
Published at DZone with permission of Michael Wittig. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments