Avoiding throttling issues altogether using asynchronous Lambda invocation

0

On an account that has a limit of 10 concurrent invocations limit, I have noticed that calling the Lambda function synchronously in short intervals can cause throttling issues (502 errors - some requests are simply rejected due to limit reach).

However, if the same function is called multiple times at very short intervals asynchronously (using InvocationType: Event), then all succeed.

My question, is this a feasible way to avoid all those throttling issues altogether ? Simply calling the function asynchronously ? Would this work always flawlessly,

Thank you.

WM
posta un anno fa544 visualizzazioni
2 Risposte
1
Risposta accettata

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.

profile pictureAWS
con risposta un anno fa
profile picture
ESPERTO
verificato un mese fa
  • Thank you, that was very informative.

1

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.

profile picture
con risposta un anno fa
  • 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.

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande