Een bedrijf heeft een serverless applicatie geïmplementeerd waarbij een AWS Lambda-functie nieuwe documenten verwerkt die naar een Amazon S3-bucket zijn geüpload. Na een marketingcampagne werden veel documenten niet verwerkt. Wat moet een solutions architect doen om deze architectuur te verbeteren?

De correcte oplossing is het implementeren van een Amazon SQS-wachtrij. Wanneer S3-events direct een Lambda-functie aanroepen, kunnen gelijktijdige uploads tijdens een marketingcampagne de Lambda-concurrentielimieten overschrijden of de functie overbelasten, waardoor events verloren gaan of niet verwerkt worden. Door S3-events naar een SQS-wachtrij te sturen, worden de events gebufferd en kan Lambda ze op zijn eigen tempo verwerken, zelfs als er pieken in het verkeer zijn. SQS biedt duurzaamheid en garandeert dat berichten niet verloren gaan. De Lambda-functie kan vervolgens de SQS-wachtrij pollen en de documenten verwerken. De andere opties zijn minder effectief: Het verhogen van de Lambda timeout naar 15 minuten lost het probleem van overbelasting of verloren events niet op; het geeft de functie alleen meer tijd als de verwerking per document langer duurt. S3 bucket replicatie is bedoeld voor redundantie en disaster recovery, niet voor het bufferen van events voor verwerking. Het implementeren van een extra Lambda-functie met load balancing is complexer en lost het onderliggende probleem van event buffering niet op; het zou nog steeds kunnen leiden tot verloren events als de gecombineerde concurrentielimiet wordt overschreden.