Een bedrijf draait een orderverwerkingsapplicatie op een Amazon EC2-instance die orders opslaat in een Amazon Aurora-database. Tijdens piekverkeer kan de applicatie soms niet snel genoeg orders wegschrijven. Wat moet een solutions architect doen om ervoor te zorgen dat orders zo snel mogelijk betrouwbaar naar de database worden geschreven?

De juiste oplossing is om orders naar een Amazon SQS-wachtrij te schrijven. Dit ontkoppelt de orderverwerking van de orderontvangst, waardoor de applicatie orders snel kan accepteren zonder te wachten op de database. Een Auto Scaling group met EC2-instances kan vervolgens asynchroon orders uit de SQS-wachtrij lezen en naar de Aurora-database schrijven, wat zorgt voor schaalbaarheid en veerkracht. De Application Load Balancer is hier niet direct relevant voor het lezen uit SQS, maar zou gebruikt kunnen worden voor de initiële orderontvangst. De andere opties zijn minder effectief: Het verhogen van het EC2-instancetype is een tijdelijke oplossing die de onderliggende knelpunten niet oplost en kan leiden tot overprovisioning. SNS is een pub/sub-service, niet ideaal voor duurzame opslag van individuele berichten die verwerkt moeten worden. Een database-eindpunt kan niet direct abonneren op een SNS-onderwerp om data te ontvangen. SNS is niet ontworpen voor het duurzaam opslaan van berichten die door een groep workers verwerkt moeten worden. Het voorwaardelijk schrijven naar SQS op basis van CPU-drempelwaarden introduceert complexiteit en vertraging. Het is beter om SQS consistent te gebruiken voor ontkoppeling. Geplande schaling is niet zo dynamisch als schalen op basis van de wachtrijlengte.