How to Throttle Third-Party API Calls in Serverless Architecture?
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?
Community Votes
100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Evaluates your understanding of event-driven buffering and concurrency controls to prevent downstream service overload, often tricked by confusing throttling mechanisms with capacity provisioning.
This scenario tests decoupling API Gateway from direct Lambda execution using Amazon SQS to manage traffic spikes and protect external endpoints. The community unanimously agrees that pairing an SQS buffer with Lambda reserved concurrency is the optimal solution for rate-limiting.
Option C is frequently selected due to its use of SNS, but provisioned concurrency only guarantees warm instances rather than actively throttling invocation rates, making it ineffective for preventing API overload.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Using Amazon SQS as a buffer between API Gateway and Lambda effectively absorbs traffic spikes while maintaining system stability. Configuring reserved concurrency on the Lambda function strictly caps the number of simultaneous executions to match the third-party API's safe threshold. This architecture ensures requests are processed at a controlled pace, preventing timeouts or errors from the external service.Why the Other Options Are Wrong
Option A relies on DynamoDB streams, which lack native concurrency throttling and would still trigger uncontrolled Lambda invocations during peak loads. Option C utilizes SNS with provisioned concurrency, but provisioned concurrency reserves capacity rather than enforcing rate limits, failing to address the overload requirement. Option D incorrectly applies Athena, an analytical query service, to real-time transactional workflows, introducing unacceptable latency and architectural mismatch.Community Comment Notes
Candidates overwhelmingly validate option B as the industry-standard pattern for this certification objective. Contributors emphasize the decoupled flow where API Gateway writes to SQS, allowing Lambda to poll and process messages safely. Multiple users note that this exact configuration aligns with AWS best practices for handling unpredictable traffic and external dependency limits.Official Reference
Exam Strategy
When a question emphasizes protecting third-party APIs or managing peak traffic, prioritize message queuing solutions paired with explicit concurrency limits. Always distinguish between reserved concurrency, which actively throttles invocations, and provisioned concurrency, which merely pre-warms capacity without controlling throughput.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →