Un ambiente di integrazione ha una coda SQS che attiva una funzione Lambda per trasformare i messaggi e chiamare un'API di terze parti. L'aumento dell'utilizzo fa sì che l'API di terze parti restituisca molti errori HTTP 429 Too Many Requests, bloccando l'elaborazione dei messaggi. Come dovrebbe risolvere il problema lo sviluppatore?

L'opzione corretta è impostare la concurrency massima sulla sorgente eventi SQS in modo che corrisponda ai limiti di frequenza documentati dell'API di terze parti. Questo approccio consente di controllare il numero di invocazioni Lambda simultanee che elaborano i messaggi dalla coda SQS, prevenendo il sovraccarico dell'API di terze parti e gli errori HTTP 429. La funzione Lambda elaborerà i messaggi a una velocità che l'API di terze parti può gestire, garantendo un'elaborazione affidabile. Aumentare la dimensione del batch della sorgente eventi SQS (opzione A) potrebbe aggravare il problema, poiché ogni invocazione Lambda elaborerebbe più messaggi contemporaneamente, aumentando potenzialmente il carico sull'API di terze parti. Configurare la concurrency provisioned per la funzione Lambda (opzione B) è utile per ridurre la latenza di avvio a freddo, ma non limita la velocità di elaborazione complessiva rispetto ai limiti dell'API esterna. Aumentare i tentativi di retry asincroni di Lambda e l'età massima dell'evento (opzione C) è una strategia per la resilienza in caso di fallimenti temporanei, ma non previene il problema di sovraccarico iniziale dell'API.