SAA-C03 Design Resilient Architectures Practice Question

A system processes events from Amazon SQS and sometimes sees duplicate messages due to retries. The business requirement is that each payment must be charged at most once. What design choice best addresses this resiliency requirement?

⚠ Common exam trap

Many exam-takers assume SQS guarantees exactly-once delivery or that increasing visibility timeouts can prevent duplicates, but SQS is designed for at-least-once delivery, and the only reliable way to handle duplicates is to make the consumer idempotent.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Implement idempotent processing using a deduplication key (for example, paymentId) and record completed charges so duplicates are safely ignored.

Implementing idempotent processing with a deduplication key (e.g., paymentId) ensures that even if duplicate messages arrive from SQS (due to retries or at-least-once delivery), the consumer can check a record of completed charges and safely ignore duplicates. This satisfies the business requirement of charging each payment at most once without relying on SQS’s best-effort deduplication or message ordering.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Assume duplicates never occur because the consumer deletes messages immediately after receiving them.
Why it's wrong here
With SQS at-least-once delivery, duplicates can still occur if processing fails, times out, or crashes before the delete occurs. Even if you delete quickly after receiving, failures after the side effect can still lead to duplicates being delivered later.
✓
Implement idempotent processing using a deduplication key (for example, paymentId) and record completed charges so duplicates are safely ignored.
Why this is correct
Idempotency ensures at-most-once side effects even when duplicates are delivered. Persist a record keyed by paymentId (e.g., a unique constraint/conditional write). If the record indicates the payment was already charged, skip the charge for any subsequent duplicate message.
✗
Increase the SQS visibility timeout until duplicates never happen.
Why it's wrong here
Increasing the SQS visibility timeout only postpones redelivery of messages that were not deleted within the allocated time; it does not alter SQS's at-least-once delivery semantics. If a consumer processes a charge but then crashes before deleting the message, the message will become visible again after the timeout and be delivered to another consumer, causing a duplicate side effect. Longer visibility timeouts also delay legitimate retries after transient failures, potentially increasing end-to-end latency while still failing to prevent duplicate processing. Visibility timeout is a mechanism for managing in-flight messages, not a deduplication control.
✗
Use SNS topics instead of SQS so retries are disabled by default.
Why it's wrong here
Switching to SNS does not eliminate duplicate notifications because SNS is a pub/sub service with at-least-once delivery to subscriptions, and HTTP/S endpoints can retry failed deliveries. Subscribers can also receive the same message multiple times due to client-side retries or network timeouts, and SNS has no built-in exactly-once semantics across consumers. In fact, using SNS directly for payment processing would still require idempotency checks to avoid double charges, and SNS lacks the visibility-timeout and message-deletion workflow that SQS provides to manage processing failures. The correct approach is to keep the queue and make the consumer idempotent.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question