Een applicatie gebouwd met Amazon API Gateway, AWS Lambda en Amazon DynamoDB retourneert een toenemend aantal fouten voor PUT-verzoeken. De meeste PUT-verzoeken komen van een kleine set clients die zijn geauthenticeerd met API-sleutels, en één client genereert veel van de verzoeken. De API is niet-kritiek en clients kunnen mislukte verzoeken opnieuw proberen, maar zichtbare fouten schaden de klantperceptie. Wat moet u aanbevelen om de klantervaring te verbeteren?

De correcte optie is het toepassen van throttling met een API Gateway usage plan. Dit is de meest effectieve oplossing omdat het de belasting van de API beheert door het aantal verzoeken per client te beperken, vooral van de client die veel verzoeken genereert. Hierdoor worden de downstream-services (Lambda en DynamoDB) beschermd tegen overbelasting, wat leidt tot minder fouten. De client kan vervolgens 429 (Too Many Requests) antwoorden ontvangen en deze op een gecontroleerde manier afhandelen, bijvoorbeeld door opnieuw te proberen met een backoff-strategie, wat de klantervaring verbetert door minder zichtbare fouten. Het toevoegen van retry-logica in de client is nuttig, maar lost de onderliggende oorzaak van de fouten (overbelasting) niet op. API-caching is niet relevant voor PUT-verzoeken, aangezien deze de status van de resource wijzigen en niet cachebaar zijn. Gereserveerde concurrency op Lambda garandeert capaciteit, maar voorkomt niet dat één client de API overbelast en andere clients beïnvloedt.