SAA-C03 Design Resilient Architectures Practice Question

• A.Assume duplicates never occur because the consumer deletes messages immediately after receiving them.
• ✓ B.Implement idempotent processing using a deduplication key (for example, paymentId) and record completed charges so duplicates are safely ignored.
• C.Increase the SQS visibility timeout until duplicates never happen.
• D.Use SNS topics instead of SQS so retries are disabled by default.

Why B: Option B is correct because 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.

• A.Keep the queue as SQS Standard but increase the visibility timeout so duplicates are less likely to reappear during timeouts.
• B.Change the queue to an SQS FIFO queue and use a stable deduplication ID derived from the payment instruction ID.
• ✓ C.Make the downstream processor idempotent by recording processed payment instruction IDs in a durable datastore and ignoring repeats.
• D.Use an ALB health check to restart the downstream processor when timeouts occur.

Why C: Option C is correct because making the downstream processor idempotent ensures that duplicate payment instructions are safely ignored, even if the same message is delivered more than once. This approach provides the strongest guarantee against duplicate side effects without requiring changes to the queue type or increasing visibility timeouts, and it keeps the system fully decoupled.

• A.Rely on SQS Standard to provide exactly-once delivery for each message, since the consumer uses retries.
• ✓ B.Implement idempotent processing using a persistent deduplication key (for example, paymentInstructionId) so repeated messages are ignored or safely merged.
• C.Increase the queue’s visibility timeout to 24 hours so messages never reappear even if the consumer times out.
• D.Delete and recreate the queue with a different name whenever duplicates are detected in production.

Why B: Option B is correct because implementing idempotent processing with a persistent deduplication key (e.g., paymentInstructionId) ensures that even if SQS Standard delivers the same message multiple times due to consumer timeouts and retries, the downstream logic will detect and ignore or safely merge duplicate charges. This is the most resilient application-side approach as it does not rely on queue configuration changes and works within the constraints of SQS Standard's at-least-once delivery model.

• A.Set the SQS visibility timeout extremely long so the message cannot be retried even after processing failures.
• ✓ B.Make the consumer idempotent by deriving a deterministic idempotency key from the payment instruction (for example, the instruction ID), persisting the result of successful processing, and skipping re-processing when that key is already marked successful.
• C.Switch to an SQS FIFO queue but remove error handling in the consumer so duplicates never occur.
• D.Send all failed messages to a DLQ and rely on it to deduplicate messages that were already successfully processed.

Why B: Option B is correct because making the consumer idempotent ensures that even if the same payment instruction is processed multiple times due to timeouts or crashes, the system remains consistent. By deriving a deterministic idempotency key (e.g., the instruction ID) and persisting the result of successful processing, the consumer can skip re-processing when the key is already marked as successful. This approach aligns with the requirement to keep the design resilient without guaranteeing exactly-once processing, as it safely handles duplicates at the application level.