Exam AWS Certified Developer Associate topic 1 question 196 discussion

https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-api

In practice, I'd go with D. I'd send a message in an async way to SQS and forget about it. Option "B" also looks appropriate. But look: the question says "service performs critical operations". Creating tons of costly threads can degrade the performance and reduce system availability (hello from Java). Tricky one to be honest.

B.- The web service would initiate the PutMetricData API call in a separate background thread. - The main thread of the web service can continue processing the client request and generating the response without waiting for the metric data submission to complete. - This approach ensures that the web service returns results to the caller as quickly as possible, improving response time. D. - Involves sending metric data to an SQS queue instead of directly calling the PutMetricData API. - An AWS Lambda function is configured to process messages from the SQS queue and call the PutMetricData API. - By using SQS, the web service can offload the metric data submission task and proceed with generating the response without waiting for the API call to complete. - However, compared to option B, this approach introduces additional complexity with the SQS queue and Lambda function setup.

B, Spawning a thread is faster than D. because in D you'd have to wait for one request-response cycle anyway but to SQS instead of CloudWatch

Mmm I am not sure about this one and I won't vote. In my opinion D works perfectly. I am not able to exclude the B given that also a separate thread can be a good solution to manage API calls in background. The question is: once I receive data from the webservice, do I have to send critical data to an SQS queue or to a specific thread? If you choose one, why the other is not correct?

Option B is the best solution because it allows the web service to call the PutMetricData API in a background thread. This means that the web service can continue to perform other critical activities without being blocked by the PutMetricData API call. The response time of the web service will not be affected by the time it takes to send metric data to CloudWatch. Also, if there is a failure when sending metric data to CloudWatch, the web service will not be impacted as the PutMetricData API call is noncritical.

Since result from putMetric is not needed, using multi-threads to perform two different jobs should be the the best case

Option D suggests sending metric data to an Amazon SQS queue and then processing it in an AWS Lambda function. While this approach can offload the processing of the metrics to the Lambda function, it introduces additional latency as the metrics need to be queued and then processed by the Lambda function, which can take some time. Additionally, the question specifically mentions that the response data from the PutMetricData API is not necessary to create the web service response. Therefore, it is not necessary to wait for a response from the API before returning a response to the caller. On the other hand, Option B suggests calling the PutMetricData API in a background thread, which can improve the response time of the web service since the API call can be made asynchronously without waiting for a response. This approach can help decouple the metric publishing process from the web service response, allowing the web service to return results to the caller as quickly as possible.

Ah, finally settled with a solid proof. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html PutMetricData can handle 500 transactions per second (TPS), which is the maximum number of operation requests that you can make per second without being throttled P.S. My "contributor" privilege is up, can't afford renewal with sky high inflation. This is probably my last post. Good luck everyone chasing whatever days left of C01 and exciting upcoming C02 adventure.

B is not correct. If a background thread is started within a Lambda function and any work is still running after the lambda timeout expires, the thread will be forcibly terminated. Starting a background thread within a Lambda function can be a useful technique, but it's important to be aware of the potential implications on function execution time. The correct answer is D as the adopted approach is asynchronous which goes in line with the requirement to return results to the caller as quickly as possible as we don't care if the response data from PutMetricData API is received or not to create a web service response.

The answer is D, and I'm 100% positive. Using SQS will make our request async. We will send the metric to a queue to be handled by another Lambda function. We won't have to wait for the answer from CloudWatch. This will improve response time. Those who suggested B, it is not correct because using background threads to publish monitor data is not a good idea either. Because while the container is not handling any request, it is in the frozen state. AWS Lambda doesn’t allocate CPU resource/slot in frozen state, so background threads can’t publish monitoring data. If data publishing takes place during request execution, it increases the duration.

Why Synchronous , generating an event is the quick thing what I feel.

Choosing D

IMHO it makes no sense to replace PutMetricsData with SQS Queue sent API. The latter may or may not be faster. I don't see any clear indication that PutMetricsData is slower? I only checked Java SDK, but I'm pretty sure any AWS-SDK supports asynchronous requests invocation (e.g. in a background thread) which for me suggests A.

it's D everyone!

b or d. b makes more logical sense, d is more amazon

D. Regarding C, it makes no sense to use synchronous processing.