It's a common pattern within my team to trigger a lambda from an Dynamo event stream.
For example, say when you delete an account you also want to delete any child accounts that are parented to the deleted account.
Currently what we do trigger the deletion from an api call, so DELETE /account/:accountId to the accounts-resource-api. This will result in a dynamo stream which triggers a lambda via Event Bridge and then SQS which will call DELETE /account/:accountId for each child account associated with the parent account.
Alternatively we could remove the need for the lambda and have the account-resource-api itself respond to the dynamo events via event bridge -> sqs and do the deletion.
I see that there is an npm library called sqs-consumer (we are using NodeJS btw) which will handle the sqs interaction for the API.
I'd like to understand the pros and cons of having the API respond to the events instead of a lambda and whether this would be considered good or bad practice.
Some concerns I have is
- How to handle dead letters,
- Additonal load on the API due to polling
Why I'm exploring this idea is to reduce the amount of workers have to build and maintain by removing the need to build "glue" lambdas that are just a proxy to pickup an event and call an api endpoint as a result
It would be good to also hear from those who have set this up before and what your learnings were and are you still using this pattern?
Top comments (0)