Answer: Use the ChangeMessageVisibility API call to increase the visibility timeout.

## 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: 1. An EC2 instance receives a message from the SQS queue 2. The message becomes invisible (visibility timeout starts) 3. The instance processes the message and writes to RDS 4. If processing takes longer than the visibility timeout, the message becomes visible again in the queue 5. 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 `ChangeMessageVisibility` with 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: 1. Estimate the maximum processing time for messages 2. Set the initial visibility timeout longer than this estimate 3. Implement `ChangeMessageVisibility` calls to extend the timeout if processing takes longer than expected 4. Delete the message from the queue only after successful processing and database commit 5. 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.

Author: LeetQuiz Editorial Team