Un'applicazione basata su Amazon API Gateway, AWS Lambda e Amazon DynamoDB sta restituendo un numero crescente di errori per le richieste PUT. La maggior parte delle richieste PUT proviene da un piccolo gruppo di client autenticati con chiavi API, e un client sta generando molte delle richieste. L'API non è critica e i client possono ritentare le richieste fallite, ma gli errori visibili stanno danneggiando la percezione del cliente. Cosa dovresti raccomandare per migliorare l'esperienza del cliente?

L'opzione corretta è applicare il throttling con un piano di utilizzo di API Gateway per le chiavi API. Questo perché il problema è causato da un piccolo gruppo di client, in particolare uno, che genera un elevato volume di richieste PUT. Il throttling su API Gateway permette di limitare il numero di richieste che un client può effettuare in un dato periodo, prevenendo che un singolo client sovraccarichi l'API e causi errori per tutti. I client riceveranno risposte 429 (Too Many Requests), che possono essere gestite in modo appropriato (ad esempio, con retry con exponential backoff) per migliorare l'esperienza complessiva senza sovraccaricare il backend. Aggiungere la logica di retry con exponential backoff e jitter nell'applicazione client è una buona pratica generale, ma non risolve la causa principale del problema, ovvero il sovraccarico causato da un client. Abilitare la cache API non è utile per le richieste PUT, che modificano i dati. Impostare la reserved concurrency sulle funzioni Lambda potrebbe aiutare a prevenire il throttling lato Lambda, ma non impedisce al client di inviare troppe richieste inizialmente, spostando potenzialmente il problema altrove o aumentando i costi inutilmente.