- 최신
- 최다 투표
- 가장 많은 댓글
It is possible that using the asynchronous InvocationType (Event) when calling a Lambda function can help to avoid throttling issues in cases where the concurrent invocations limit has been reached. This is because the Event invocation type allows multiple requests to be handled concurrently, whereas the default RequestResponse invocation type processes requests one at a time.
However, it is important to note that using the Event invocation type may not always work flawlessly to avoid throttling issues. This is because the Event invocation type is not guaranteed to deliver the results of the function in the order that the requests were made. Additionally, the Event invocation type may not be suitable for all use cases, as it does not provide a way to obtain the result of the function directly.
In general, it is a good practice to design your Lambda functions and the calling application in a way that avoids reaching the concurrent invocations limit. This can be done by using techniques such as batching requests, or by using a queueing service such as Amazon SQS to buffer requests before they are sent to the Lambda function.
Any reason you want such a low limit on concurrent invocations when your question is about running more at once? You can request a quota increase? Am I missing something that makes you need a different solution?
I do agree with Dylan's answer that async behaves a bit differently and would be the preferred design pattern.
I understand that increasing the limit solves the issue for concurrent invocations (synchronously). Another solution, I understand, is to use asynchronous invocations, order does not matter. What matters is that all requests will be processed. And there is also the dead lock feature, which can notify about failed ones. Amazon SQS or batching from my side can also be a third solution. Thank you, your input is valuable.
Thank you, that was very informative.