DVA-C02 · Question #325
A company has built a serverless application for its ecommerce website. The application includes a REST API in Amazon API Gateway that invokes an AWS Lambda function. The Lambda function processes dat
The correct answer is C. Configure the REST API in API Gateway to write the requests directly into an Amazon Simple. Option C likely completes as "Amazon Simple Queue Service (SQS)" - the correct architecture here is API Gateway → SQS → Lambda → third-party API. SQS acts as a buffer, absorbing burst traffic and allowing Lambda to consume messages at a controlled rate (via reserved concurrency a
Question
A company has built a serverless application for its ecommerce website. The application includes a REST API in Amazon API Gateway that invokes an AWS Lambda function. The Lambda function processes data and stores the data in Amazon DynamoDB table. The Lambda function calls a third-party stock application API to process the order. After the ordered is processed, the Lambda function returns an HTTP 200 status code with no body to the client. During peak usage when the API calls exceeds a certain threshold, the third-party stock application sometimes fails to process the data and responds with error messages. The company needs a solution that will not overwhelm the third-party stock application. Which solution will meet these requirements?
Options
- AConfigure the REST API in API Gateway to write the requests directly into DynamoDB. Configure
- BConfigure the REST API in API Gateway to write the requests directly into an Amazon Simple
- CConfigure the REST API in API Gateway to write the requests directly into an Amazon Simple
- DConfigure the REST API in API Gateway to write the requests directly into Amazon Athena.
How the community answered
(22 responses)- A9% (2)
- B5% (1)
- C82% (18)
- D5% (1)
Explanation
Option C likely completes as "Amazon Simple Queue Service (SQS)" - the correct architecture here is API Gateway → SQS → Lambda → third-party API. SQS acts as a buffer, absorbing burst traffic and allowing Lambda to consume messages at a controlled rate (via reserved concurrency and batch size settings), preventing the third-party stock API from being flooded during peak load. This also enables the client to receive an immediate acknowledgment while the order is processed asynchronously.
Why the distractors fail:
- A (DynamoDB): DynamoDB is a database, not a message queue. Pointing API Gateway directly at it provides no rate-limiting mechanism for downstream API calls.
- B (SNS): SNS is a push-based pub/sub service - it fans out messages immediately to all subscribers without buffering, so it cannot smooth out traffic spikes to the third-party API.
- D (Athena): Athena is an analytics query service for S3 data; it has no role in real-time order processing or traffic control.
Memory tip: When a question mentions "overwhelm," "throttle," or "rate-limit a downstream service," think SQS as a shock absorber - it decouples producers from consumers and lets you tune throughput on the consumer side independently of incoming request volume.
Topics
Community Discussion
No community discussion yet for this question.