Exam AWS Certified Solutions Architect - Associate SAA-C02 topic 1 question 347 discussion

"we discussed the Request-Response Messaging Pattern. In this pattern, each requester creates a temporary destination to receive each response message. The simplest approach is to create a new queue for each response, but this is like building a road just so a single car can drive on it before tearing it down. Technically, this can work (and SQS can create and delete queues quickly), but we can definitely make it faster and cheaper. To better support short-lived, lightweight messaging destinations, we are pleased to present the Amazon SQS Temporary Queue Client. This client makes it easy to create and delete many temporary messaging destinations without inflating your AWS bill." https://aws.amazon.com/blogs/compute/simple-two-way-messaging-using-the-amazon-sqs-temporary-queue-client/ C

Answer D as per: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/working-with-messages.html#implementing-request-response-systems

C is the answer

CCCCCCCCCCCC

What is the correct option ?

CCCCCCCCCCCCC

Vote C.

Temp SQS Q supports RR

temporary queue

To implement this pattern: use the SQS Temporary Queue Client. It leverages virtual queues instead of creating / deleting SQS queues (cost-effective).

C A. Configure a dead-letter queue on the ReceiveMessage API action of the SQS queue. - Wrong. This is a generic solution for handling messages that can't be processed successfully. Our solution should be targeted to SQS used in a request-response paradigm - https://aws.amazon.com/blogs/compute/simple-two-way-messaging-using-the-amazon-sqs-temporary-queue-client/ B. Configure a FIFO queue, and use the message deduplication ID and message group ID. - Wrong. A FIFO queue further limits our messages per second to ~400, which won't scale C. Create a temporary queue, with the Temporary Queue Client to receive each response message. - Correct. https://aws.amazon.com/blogs/compute/simple-two-way-messaging-using-the-amazon-sqs-temporary-queue-client/ D. Create a queue for each request and response on startup for each producer, and use a correlation ID message attribute. - Wrong. Creating physical queues for each API request/response will cause significant overhead and won't scale. Having logical / virtual queues via the SQS Temporary Queue Client solves this

ANS = C

C-Temporary Queue Client Directly from Stephane's AWS course, Request Response Systems can be implemented using 'SQS Temporary Queue Client'. We have single request queue and the responses are kept into different queues(correlation ID helps track response) The producer can take in responses as convenient from this response queue.

Its C - temp Q is a common pattern for replacing Request-Response to SQS

CCCCCCCCCCCCCCC The most common use case for temporary queues is the request-response messaging pattern, where a requester creates a temporary queue for receiving each response message. To avoid creating an Amazon SQS queue for each response message, the Temporary Queue Client lets you create and delete multiple temporary queues without making any Amazon SQS API calls. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-temporary-queues.html#request-reply-messaging-pattern

One huge point you guys have missed. D mentions request and response and C only mentions the word response. I am changing from C to D.

I think A is actually the best answer. Based on the info given in the case, no conclusions can be made yet as to why not all messages are being processed. The dead-letter queue is a perfect way to capture the unprocessed messages and analyze them. "The main task of a dead-letter queue is handling message failure. A dead-letter queue lets you set aside and isolate messages that can’t be processed correctly to determine why their processing didn’t succeed. " see https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html