An SQS-triggered fee-posting Lambda can be invoked more than once for the same message because of at-least-once delivery. Double posts would corrupt municipal ledgers. What must the handler do?
Select an answer to reveal the explanation.
Short Explanation
SQS can knock twice—treat fee posting like a stamped voucher, not a blank check. Conditional writes or dedupe tokens keep a second delivery from double-charging the ledger. Hoping for exactly-once delivery is wishful thinking.
Full Explanation
An SQS-triggered fee-posting Lambda can be invoked more than once for the same message because of at-least-once delivery; double posts would corrupt municipal ledgers, so the handler must be idempotent using conditional writes or deduplication tokens so repeated deliveries do not create duplicate ledger posts. Natural keys (account + fee period + fee type) with conditional PutItem/TransactWrite, or an explicit processed-message table, turn broker redelivery into a safe no-op after the first successful post.
Assuming SQS exactly-once delivery and writing blindly is unsafe for standard queues and still fragile even with FIFO. Disabling the queue’s visibility timeout so duplicates never occur breaks the receive/delete protocol and causes chaotic re-processing. Deleting the DynamoDB table after each successful post to prevent duplicates is destructive nonsense.
Exam caveat: idempotency belongs in the ledger write, not only in “maybe FIFO will save us.” Include correlation IDs from the message into audit rows. Test intentional double delivery in non-prod before tax season.
Operational check: implement conditional ledger writes; replay the same SQS message twice in test; confirm one post; metricate duplicate suppressions; and alarm on unexpected ConditionalCheckFailed spikes that might indicate key-design bugs.