Un'applicazione legacy è stata migrata in una funzione Lambda che esegue molte chiamate API di terze parti per estrarre dati a fine mese, quindi li elabora per produrre report mensili. Il fornitore di terze parti ha introdotto dei limiti: un numero fisso di chiamate API al minuto e al giorno (fornito nelle intestazioni di risposta), restituendo errori quando i limiti vengono superati. L'intera esecuzione dell'elaborazione dei dati potrebbe ora richiedere giorni se l'applicazione deve rallentare per evitare di superare i limiti. Qual è il modo più efficiente dal punto di vista operativo per rifattorizzare questo workflow serverless per rispettare tali limiti?

La soluzione con AWS Step Functions è la più efficiente operativamente perché Step Functions è progettato per orchestrare workflow complessi e di lunga durata, come quello descritto. Utilizzando uno stato Wait basato sui fallimenti dovuti ai limiti di velocità, Step Functions può gestire automaticamente i ritardi e i tentativi, rispettando i limiti API senza richiedere logica complessa nella funzione Lambda. Questo riduce il carico operativo e la complessità del codice. Le altre opzioni sono meno adatte: Inviare le attività a una coda SQS e farle elaborare da una Lambda richiede una logica personalizzata per gestire i ritardi e i tentativi, aumentando la complessità operativa. Creare una metrica CloudWatch Logs e un allarme per arrestare la Lambda non risolve il problema, ma lo interrompe, impedendo il completamento del processo. Utilizzare Kinesis Data Firehose per raggruppare le richieste e consegnarle a S3 non è appropriato per gestire limiti di velocità su chiamate API esterne in tempo quasi reale; è più adatto per l'ingestione di dati in streaming.