AWS Certified Solutions Architect - Associate
Get started today
Ultimate access to all questions.
Deep dive into the quiz with AI chat providers.
We prepare a focused prompt with your quiz and certificate details so each AI can offer a more tailored, in-depth explanation.
A company hosts an application on multiple Amazon EC2 instances. The application processes messages from an Amazon SQS queue, writes to an Amazon RDS table, and deletes the message from the queue. Occasional duplicate records are found in the RDS table. The SQS queue does not contain any duplicate messages.
What should a solutions architect do to ensure messages are being processed once only?
Other
Community
UAnonymous
A
Use the CreateQueue API call to create a new queue.
B
Use the AddPermission API call to add appropriate permissions.
C
Use the ReceiveMessage API call to set an appropriate wait time.
D
Use the ChangeMessageVisibility API call to increase the visibility timeout.
Explanation:
Explanation
When duplicate records appear in the RDS table despite no duplicate messages in the SQS queue, this indicates that messages are being processed more than once by different EC2 instances. This typically happens due to visibility timeout issues in SQS.
How the Problem Occurs:
- An EC2 instance receives a message from the SQS queue
- The message becomes invisible (visibility timeout starts)
- The instance processes the message and writes to RDS
- If processing takes longer than the visibility timeout, the message becomes visible again in the queue
- Another EC2 instance picks up the same message, processes it again, and creates a duplicate record
Solution:
Option D - Use the ChangeMessageVisibility API call to increase the visibility timeout is correct because:
- ChangeMessageVisibility allows you to extend the visibility timeout for a specific message
- This ensures that if message processing takes longer than expected, the message won't become visible again prematurely
- The application should call
ChangeMessageVisibilitywith a new timeout value that's longer than the expected processing time - This prevents other consumers from receiving the same message while it's still being processed
Why Other Options Are Incorrect:
A. CreateQueue API call - Creating a new queue doesn't solve the duplicate processing issue; it just creates another queue with the same problem.
B. AddPermission API call - This is for managing access permissions to the queue, not for preventing duplicate message processing.
C. ReceiveMessage API call with wait time - While setting appropriate wait times can optimize polling, it doesn't prevent duplicate processing when visibility timeouts expire.
Best Practice Implementation:
- Estimate the maximum processing time for messages
- Set the initial visibility timeout longer than this estimate
- Implement
ChangeMessageVisibilitycalls to extend the timeout if processing takes longer than expected - Delete the message from the queue only after successful processing and database commit
- Consider using SQS FIFO queues if exactly-once processing is critical (though this wasn't an option in the question)
This approach ensures idempotent processing where messages are processed exactly once, even in distributed systems with multiple consumers.
Comments
Loading comments...