A Lambda function processes messages from an SQS standard queue and writes results to DynamoDB. Duplicate writes occasionally occur after retries. Which two changes best make the processing idempotent?
SQS Standard queues provide at-least-once delivery, meaning messages can be delivered multiple times. Implementing idempotency is crucial to prevent duplicate processing side effects. By generating a deterministic key (e.g., from the SQS message ID or a business transaction ID) and storing it in DynamoDB with a conditional write (e.g., using `attribute_not_exists`), the Lambda function ensures that the operation only proceeds if the key hasn't been recorded before, making the operation safe for retries and preventing unintended state changes.
Why this answer
Using a deterministic idempotency key (e.g., a business transaction ID) combined with a conditional write in DynamoDB ensures that if the same message is processed more than once, the second write attempt will fail because the item already exists. This prevents duplicate records even when Lambda retries after a failure or timeout, making the processing idempotent at the database level.
Exam trap
The trap here is that candidates often confuse idempotency with simply increasing timeouts or disabling visibility timeouts, not realizing that idempotency requires a deterministic key and a conditional check at the storage layer.