I haven't used Step Function for this. Up til now, it hasn't got a built-in concurrency control mechanism. In fact, when I needed to limit the concurrency of some state in my state machine, I've had to implement that concurrency control outside of the state machine, for example, like this theburningmonk.com/2018/07/step-functions-how-to-implement-semaphores-for-state-machines
This is a preview lesson from my cohort-based workshop, "Production-Ready Serverless". If you liked this, then please check out the full curriculum at productionreadyserverless.com. You can get 15% OFF with the code "TH-cam15" during checkout. Hope to see you there!
IoT core is an async invocation source for Lambda, and assuming that you're working on an IoT solution then you're kinda stuck with it. So for concurrency control in this situation, I think you should use reserved concurrency. But if you need to allocate a large no. of concurrency units across multiple functions then you should consider isolating your IoT event processing functions to a their own account. That way, your other systems, like APIs, are shielded from whatever concurrency units that you have to reserve for your IoT functions.
Best video on concurrency
Thank you!
Excellent video, thanks for sharing
Thank you, glad you liked it!
Thank you!
Fantastic video! Do you ever reach for step functions to solve this problem?
I haven't used Step Function for this. Up til now, it hasn't got a built-in concurrency control mechanism. In fact, when I needed to limit the concurrency of some state in my state machine, I've had to implement that concurrency control outside of the state machine, for example, like this theburningmonk.com/2018/07/step-functions-how-to-implement-semaphores-for-state-machines
This is a preview lesson from my cohort-based workshop, "Production-Ready Serverless". If you liked this, then please check out the full curriculum at productionreadyserverless.com.
You can get 15% OFF with the code "TH-cam15" during checkout. Hope to see you there!
What's the best practice to handle Lambda concurrency for IoT core message topics?
IoT core is an async invocation source for Lambda, and assuming that you're working on an IoT solution then you're kinda stuck with it.
So for concurrency control in this situation, I think you should use reserved concurrency. But if you need to allocate a large no. of concurrency units across multiple functions then you should consider isolating your IoT event processing functions to a their own account.
That way, your other systems, like APIs, are shielded from whatever concurrency units that you have to reserve for your IoT functions.
Is there an option to set scalingconfig maximumConcurrency in aws console while setting sqs-lambda trigger?
Yup, you can set it in the console when you configure a SQS trigger for a Lambda function. It's called "Maximum concurrency".
Made me hungry!