Q57 — AWS SAA-C03 Ch.17

Question 57 of 89 | ← Chapter 17

Q1357. A company has an ecommerce application that users access users access through multiple mobile apps and web applications. The company needs a solution that will receive requests from the mobile apps and web applications through an API.Request traffic volume varies significantly throughout each day. Traffic spikes during sales events. The solution must be loosely coupled and ensure that no requests are lost.Which solution will meet these requirements?

Correct Answer: B. Set up an Amazon API Gateway REST API with an integration to an Amazon SQS queue. Configure a dead-letter queue. Create an AWS Lambda function to poll the queue to process the requests.

Explanation

The correct answer is B. Set up an Amazon API Gateway REST API with an integration to an Amazon SQS queue. Configure a dead-letter queue. Create an AWS Lambda function to poll the queue to process the requests.Explanation:The company needs a scalable, loosely coupled, and resilient solution to handle variable request traffic (including spikes during sales events) without losing any requests.Key Requirements:Loosely coupled architecture Decouple the API frontend from the backend processing. No lost requests Ensure requests are persisted even under high load.Scalability Handle traffic spikes efficiently.API-based access Accept requests from mobile and web apps via an API.Why Option B is the best choice:Amazon API Gateway REST API Provides a secure, scalable API endpoint for mobile and web apps.Amazon SQS IntegrationDecouples the API frontend from the backend processing.Stores requests in a queue (persistent storage), ensuring no requests are lost even under high load. Handles traffic spikes by buffering requests until they can be processed. Dead-letter queue (DLQ) Captures failed requests for reprocessing or debugging.AWS Lambda polling the queueScales automatically to process messages as they arrive.No need for manual scaling (unlike EC2-based solutions).Why the other options are incorrect:A. ALB + Elastic BeanstalkTightly coupled (ALB directly routes to Elastic Beanstalk, which may struggle under traffic spikes). No built-in queuing Requests may be lost if Elastic Beanstalk is overwhelmed.Less scalable than a queue-based solution.C. ALB + Lambda (as ALB target)Lambda as an ALB target is not ideal for variable trafficALB expects HTTP responses, but Lambda may not scale fast enough during spikes. No built-in queuing Requests may be dropped if Lambda concurrency limits are reached.Not as resilient as SQS for handling traffic surges.D. API Gateway HTTP API + SNS + LambdaSNS is a pub/sub system, not a queueNo guarantee of exactly-once processing (messages may be duplicated or lost).No built-in retry mechanism (unlike SQS).Less reliable than SQS for ensuring no lost requests.Comparison Table:OptionArchitectureDecouplingNo Lost Requests?ScalabilityBest For AALB Elastic BeanstalkTightly coupled (No queue)ModerateTraditional web apps BAPI Gateway SQS LambdaLoosely coupled(SQS persists)HighVariable traffic, no lost requests CALB LambdaSemi-decoupled (No queue)ModerateSimple API backends DAPI Gateway SNS LambdaLoosely coupled (SNS may lose/dup messages)HighEvent-driven pub/ subConclusion:Option B is the best solution because:SQS ensures no requests are lost (even during traffic spikes).Lambda scales automatically to process queued requests.Dead-letter queue improves reliability by capturing failed messages. Loosely coupled architecture improves resilience and scalability.Avoid Options A, C, and D (they lack proper queuing or are too tightly coupled).