How to Reduce Pricing for Amazon SQS without Compromising Time
Question
Your organization is using Amazon SQS as an enterprise message queuing platform.
100s of applications read the queues every few seconds to process the messages and delete them as soon as they are written into the queues.
Looking at the number of requests being sent to Amazon SQS APIs, your management is concerned about the pricing that will be incurred.
As an architect, how would you reduce pricing without compromising on time in this scenario? Please select 2 correct answers.
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.Answer: B, C.
Option A is incorrect.
There is no such limitation on AWS SQS queues.
Option B is correct.
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.htmlOption C is correct.
Option D is not correct.
Short polling does not guarantee a return of the message, and you have to repeat the call until you receive the message.
That does not reduce any costs.
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html
Amazon Simple Queue Service (Amazon SQS) is a managed message queuing service that enables decoupling and scaling of distributed systems and applications. It is a cost-effective messaging service that can be used to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be available all the time.
In the given scenario, where hundreds of applications are reading and processing messages from SQS queues every few seconds, it is natural to expect a large number of requests being sent to Amazon SQS APIs, leading to cost concerns. To reduce pricing without compromising on time, the following options can be considered:
A. Once successfully written, Amazon SQS messages are only available after 1 minute. Ask applications to increase the delay between calls to 1 minute. This reduces the number of API calls made.
This option is not suitable in the given scenario as the applications need to process messages frequently and deleting messages as soon as they are processed is crucial to avoid message duplication and other issues. Increasing the delay between calls to 1 minute may lead to slower processing and reduced system performance.
B. Use Amazon SQS Long Polling.
Long Polling is a feature in Amazon SQS that allows applications to receive messages from a queue with reduced cost and increased efficiency. In Long Polling, an application can specify a WaitTimeSeconds parameter to receive messages only when they are available, reducing the number of empty responses and hence, the number of requests sent to SQS APIs. Long Polling can also reduce the cost by minimizing the use of Short Polling, which involves sending a request to SQS every few seconds to check if there are new messages.
C. Send DeleteMessage requests in batch.
In the given scenario, applications are deleting messages from SQS queues as soon as they are processed. Instead of sending individual DeleteMessage requests for each message, the applications can send DeleteMessageBatch requests to delete multiple messages in a single request, thereby reducing the number of requests sent to SQS APIs and hence, the cost incurred.
D. Use Amazon SQS Short Polling.
Short Polling is the default mode of operation in Amazon SQS, where an application sends a request to SQS every few seconds to check if there are new messages in the queue. Short Polling can lead to increased cost and reduced efficiency as it results in empty responses when there are no new messages, leading to unnecessary API requests. Hence, using Short Polling is not recommended in the given scenario.
To conclude, options B and C are the correct answers to reduce pricing without compromising on time in the given scenario. Option A is not suitable, and option D is not recommended.
