An orders service publishes payment instructions to an Amazon SQS queue. The downstream consumer sometimes times out while processing a message. After the message becomes visible again, the consumer may process the same instruction more than once and occasionally creates duplicate orders. The team needs a resiliency-focused design that prevents duplicates from creating double-charges, even if the same message is processed multiple times. What is the best architectural change?

Rely on SQS to guarantee exactly-once delivery for standard queues and remove all duplicate-handling logic in the consumer.

Standard SQS provides at-least-once delivery, not exactly-once. Duplicates can occur due to retries after timeouts, crashes, or visibility timeouts. Removing duplicate handling increases the chance of double-charging.

Increase the SQS visibility timeout to the maximum value so the consumer never retries the message.

A longer visibility timeout reduces retry frequency but cannot guarantee that the consumer will finish processing within the timeout. If processing still exceeds the visibility timeout, the message will be delivered again and duplicates can still occur.

Change the queue to SNS with a fan-out subscription so each consumer gets a separate copy, ensuring processing is sequential and duplicate-free.

SNS fan-out does not provide exactly-once semantics. Multiple deliveries and duplicate side effects can still occur, and sequential/duplicate-free processing is not guaranteed by SNS itself.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Make the consumer idempotent by using an idempotency key from the payment instruction (for example, a unique transaction/payment ID) and storing processing results with conditional writes so repeated deliveries do not create a second order. — With standard SQS, delivery is typically at-least-once, so duplicates can happen when consumers time out, fail mid-processing, or restart. To prevent duplicate charges, design the consumer to be idempotent: derive a stable idempotency key from the payment instruction (for example, transaction ID), then use a durable store with conditional writes/uniqueness constraints so the order/charge is created only once. This remains correct even if the same message is delivered and processed multiple times. A) Standard SQS cannot guarantee exactly-once delivery, so eliminating duplicate handling is unsafe. C) Visibility timeout settings only affect retry timing; they do not eliminate duplicate delivery risk. D) SNS fan-out changes delivery topology but does not provide idempotency or exactly-once guarantees and can still result in duplicated side effects.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.