Klanten van een financiële onderneming vragen afspraken aan met adviseurs via tekstberichten. Een webapplicatie op Amazon EC2 accepteert aanvragen en publiceert de tekstberichten naar een Amazon Simple Queue Service (Amazon SQS) wachtrij. Een andere EC2-applicatie verstuurt uitnodigingen voor vergaderingen en bevestigings-e-mails, en slaat vervolgens de vergaderdetails op in een Amazon DynamoDB-tabel. Naarmate het bedrijf groeit, melden klanten dat het langer duurt voordat uitnodigingen voor vergaderingen arriveren. Wat moet een solutions architect aanbevelen om dit op te lossen?

De correcte oplossing is het toevoegen van een Auto Scaling group voor de applicatie die uitnodigingen verstuurt, geconfigureerd om te schalen op basis van de diepte van de SQS-wachtrij. Dit lost het probleem op van vertraagde uitnodigingen door ervoor te zorgen dat er voldoende verwerkingscapaciteit is wanneer de belasting toeneemt. De diepte van de SQS-wachtrij is een directe indicator van de hoeveelheid onverwerkte berichten, waardoor de Auto Scaling group proactief kan reageren op pieken in het aantal afspraakverzoeken. Het toevoegen van een DAX-cluster (DynamoDB Accelerator) is niet relevant, omdat het probleem ligt bij de verwerking van berichten uit SQS, niet bij de leesprestaties van DynamoDB. Een API Gateway of CloudFront-distributie zijn oplossingen voor de frontend of caching van webapplicaties, en zullen de achterliggende verwerkingscapaciteit van de SQS-consumer niet verbeteren.