In the last article, we went through the concept of Lambda Triggers and Destinations. As I promised, this is the second part of that article, we will dive into the technical part of triggering Lambda with SQS, API Gateway, and S3 notifications.
At the end of this article, you’ll find a GitHub link that you can clone and run the same processes I will describe in this article. Shall we begin?
As we all know, SQS is a queueing system that AWS offers and it’s highly available and resilient.
How does it work with Lambda? Is it useful? Please check the following draw.
As you can see, this is what is happening when you trigger Lambda by SQS. This draw was generated by X-Ray service. Btw, I highly recommend you guys to check it out.
I, as a client, inserted a new message into the queue. Queue sends this message to Lambda because I configured that this queue destination is associated with a Lambda. Of course, it depends on SQS configs that when it sends it, but the point is that the message arrived in Lambda. Also, the client in this draw means any service that can send messages to the queue.
I love giving examples and this is what I’m going to do now.
Imagine you have a cool website that sells mugs. I launched a new collection for Star Wars fans. You faced an issue that your Lambda concurrent reached the max and most of the functions got affected. How to solve this issue? SQS!!.
Let’s dream and said you have 13k orders each hour. You need to process them asap but you don’t have the needed resources. Your lambdas are under pressure and ProceessOrder function is exhausting most of the computing power. Simply, limit the concurrent requests to a comfortable limit and use SQS to ingest these requests. If something went wrong, don’t worry because it has a retry mechanism that will try a few times if your computing unit is unreachable at that specific moment.
How to test it?
1- Open the console, and click on SQS.
2- Select the queue you want to test, click on Queue Actions, Send a message.