Examkin

Question

Difficulty: MediumMessage-Based Integration using Amazon SQS and SNS

A high-volume logistics application uses an Amazon SQS standard queue to buffer telemetry data from delivery vehicles. A worker process retrieves messages, performs geo-spatial calculations, and writes the results to an Amazon DynamoDB table. The worker process takes up to 7575 seconds to process each telemetry payload. Currently, the SQS queue visibility timeout is set to 6060 seconds. Consequently, some telemetry records are duplicated in the DynamoDB table. Which two actions should the developer take to resolve this duplication issue?

  1. Increase the default visibility timeout of the SQS queue to 120120 seconds, ensuring it exceeds the maximum message processing time.Answer
  2. Modify the worker application to call the ChangeMessageVisibility API operation to extend the visibility timeout of a message during active processing.Answer
  3. C
    Decrease the default visibility timeout of the SQS queue to 1515 seconds so that failed messages are retried faster.
  4. D
    Hardcode static AWS access keys inside the worker application's SDK client configuration to reduce latency during credential resolution.
  5. E
    Store the application's processing state in static, global variables to maximize execution context reuse, assuming the connection pool persists without cleanup.

Answer

To resolve the duplication, the developer must increase the SQS queue's default visibility timeout to 120120 seconds and modify the worker application to dynamically call the ChangeMessageVisibility API operation during active processing.
The issue is caused by the message processing duration (7575 seconds) exceeding the default visibility timeout (6060 seconds). Increasing the visibility timeout to 120120 seconds ensures the message is not visible to other consumers during the transaction. Additionally, invoking the ChangeMessageVisibility API dynamically extends the timeout for slow messages, handling unexpected latency without permanently locking failed messages.

Step-by-Step Solution

1
Identify the cause of message reprocessing.
The worker processing time of 7575 seconds exceeds the 6060-second queue visibility timeout.
When the visibility timeout expires before the worker deletes the message, the message becomes visible to other workers, causing duplicate processing.
2
Adjust the default visibility timeout configuration.
Increase the default visibility timeout of the queue to a value greater than the maximum processing time, such as 120120 seconds.
This guarantees that under typical conditions, the message remains invisible to other workers while being processed.
3
Implement a dynamic extension safeguard.
Integrate the ChangeMessageVisibility API call within the application code to request additional visibility time if processing is still ongoing.
This prevents reprocessing in scenarios where transient issues (like database latency) extend the processing time beyond the new static limit.

Key Concept

Amazon SQS Message Visibility Timeout management and dynamic visibility updates using ChangeMessageVisibility.
Rate this question

Topics

Message-Based Integration using Amazon SQS and SNS

More questions from this topic