Which solution will meet these requirements?
Configure the REST API in API Gateway to write the requests directly into DynamoDB. Configure a DynamoDB intrinsic function to perform the transformation. Set up a DynamoDB stream to call the third-party stock application API with each new row. Delete the Lambda function.
Configure the REST API in API Gateway to write the requests directly into an Amazon Simple Queue Service (Amazon SQS) queue. Configure the Lambda function with a reserved concurrency equal to the third-party stock application’s threshold. Set Lambda function to process the messages from the SQS queue.
Configure the REST API in API Gateway to write the requests directly into an Amazon Simple Notification Service (Amazon SNS) topic. Configure the Lambda function with a provisioned concurrency equal to the third-party stock application’s threshold. Set the Lambda function to process the messages from the SNS topic.
Configure the REST API in API Gateway to write the requests directly into Amazon Athena. Configure the transformation of the data by using SQL with multiple query result locations set up to point to the DynamoDB table and the third-party stock fulfilment application API. Delete the Lambda function.
Explanations:
This option suggests writing directly to DynamoDB and using a DynamoDB stream to invoke the third-party API. However, this approach could overwhelm the stock application, as DynamoDB streams trigger actions immediately upon data changes, which doesn’t provide any rate-limiting or control over the flow of requests to the third-party API.
This option proposes using Amazon SQS to queue requests before processing them with a Lambda function. This effectively decouples the request handling from the third-party API call, allowing the Lambda function to process messages at a controlled rate. Configuring reserved concurrency for the Lambda function ensures that it does not exceed the threshold of the third-party stock application, preventing overload.
Although this option involves using Amazon SNS to push messages to the Lambda function, it does not provide the same level of control over the rate of processing as SQS. SNS would invoke the Lambda function for each message immediately, which could still overwhelm the third-party API, especially during peak loads. Provisioned concurrency alone does not limit the invocation rate effectively.
Writing requests directly into Amazon Athena is not appropriate for this use case. Athena is designed for querying data in S3, not for processing API requests or managing workflows. This option also involves deleting the Lambda function, which eliminates the ability to manage the request and response process effectively, and it does not prevent overwhelming the third-party API.