Question

Difficulty: HardMessage-Based Integration using Amazon SQS and SNS

An organization is refactoring its order fulfillment system. The system publishes order transaction events to an Amazon SNS standard topic, which fans them out to two Amazon SQS standard queues. The first SQS queue is consumed by a processing application that processes messages in batches; each batch takes up to 8 minutes to complete database writes. During peak traffic, the database shows duplicate entries for the same order because messages are being reprocessed before the first run completes. The second SQS queue is polled by an analytics application that queries the queue continuously, resulting in high API call counts and elevated costs even when no messages are present. Which two changes should the developer implement to resolve the duplicate processing issue and optimize the polling efficiency for the analytics queue? (Select TWO.)

  1. Increase the VisibilityTimeout attribute of the first SQS queue to 9 minutes, ensuring it exceeds the maximum database write time.Answer
  2. Configure the analytics application to use SQS long polling by setting the ReceiveMessageWaitTimeSeconds attribute of the second SQS queue to 20 seconds.Answer
  3. C
    Set the VisibilityTimeout of the first SQS queue to 2 minutes and configure the application client to call ChangeMessageVisibility to extend it dynamically during failures.
  4. D
    Convert the first SQS queue to a FIFO queue and enable content-based deduplication to automatically filter duplicate order transactions.
  5. E
    Enable active tracing on the SQS queues and configure the SDK client in the analytics application to use hardcoded IAM access keys with minimum permissions.

Answer

To resolve the issues, increase the VisibilityTimeout of the first SQS queue to 9 minutes to cover the 8-minute processing time, and configure long polling on the second SQS queue by setting ReceiveMessageWaitTimeSeconds to 20 seconds.
To prevent duplicate processing, the visibility timeout of the SQS queue must be set higher than the maximum processing time of 8 minutes, making the configuration of 9 minutes correct. To optimize costs and reduce empty API calls on the polling consumer, long polling must be configured by setting ReceiveMessageWaitTimeSeconds to a value up to 20 seconds.

Step-by-Step Solution

1
Analyze the cause of duplicate entries in the first queue.
The processing application takes up to 8 minutes to complete a batch, but if the visibility timeout is shorter than 8 minutes, messages become visible again to other instances before deletion, causing duplicate processing.
The visibility timeout must be set to a value greater than the maximum expected processing time.
2
Select the appropriate visibility timeout configuration.
Increase the VisibilityTimeout of the first SQS queue to 9 minutes.
This guarantees that the processing application has sufficient time to complete its database writes and delete the messages from the queue before they can be re-driven.
3
Analyze the high API call counts and costs for the second queue.
Continuous short polling returns empty responses immediately, which increases API call charges and CPU utilization.
Long polling must be enabled to allow SQS to wait for messages to arrive before returning a response.
4
Select the long polling configuration.
Set the ReceiveMessageWaitTimeSeconds attribute of the second SQS queue to 20 seconds.
Setting the value to 20 seconds maximizes long polling efficiency, reducing empty receives and associated costs.

Key Concept

Configuring SQS Visibility Timeout to match processing times and using SQS Long Polling to minimize API cost and overhead.
Rate this question