LEARN. PRACTICE. GROW.Identify the promised effect
In a fictional reconciliation integration, receiving a message does not mean completing the posting. Record the logical operation the consumer intends to execute and how it can recognize a repeat. Failure after the effect but before acknowledgment leaves an uncertain outcome for the component receiving again. The queue does not automatically coordinate a transaction with an external system. Select protection matching the operation, including concurrency and recovery. A new key per attempt can destroy that correspondence. At RUN handover, document how to distinguish pending work, completed effects, and outcomes still requiring reconciliation, including signals supporting retry or investigation.
Calculate visibility from the change
Visibility timeout provides time for processing and acknowledgment but is not a universal guarantee against duplicates. In one example, receipt occurs at t=0 with 40-second visibility. At 25 seconds, a successful change sets 60 seconds. The new deadline is t=85, measured from the change, not t=100 by adding to the former deadline. This model ignores transport latency and other changes. In implementation, plan margin, observe actual duration, and handle renewal failures. An excessive timeout also delays recovery of abandoned work. Do not confuse waiting for messages with visibility of an already received message; these configure different stages of the flow.
Bound FIFO deduplication
FIFO send deduplication covers a five-minute interval; it should not be treated as a permanent history of business effects. If the producer repeats an operation seven minutes later, that protection alone does not resolve the repeat. With content-based deduplication, the hash considers the body and excludes attributes. Different operations with identical bodies and identifiers only in attributes can collide under that mechanism. Define consistent logical identity: different operations have distinct IDs while attempts of the same operation retain the appropriate ID. The choice must also match consumer protection. Do not conclude that ordering or send deduplication establishes single execution of an external financial action.
Report failures per record
In an SQS standard integration with Lambda, a batch failure can cause already processed records to repeat. With ReportBatchItemFailures enabled and a valid response, code identifies failed message IDs in batchItemFailures. It returns neither receipt handles nor a list of successes. If the function throws an unhandled exception, the batch is considered a complete failure despite the configuration. An empty list communicates success. Tests therefore need to examine configuration and response as well as logs. In this lesson’s models, compare the set that should be retried with the set actually returned and include failures occurring after some work has completed.
Preserve required ordering
The ordering boundary should match the business requirement. If ordering is needed only per account, a stable MessageGroupId per account permits independence across groups. Using global for everything creates a broader serialization boundary. Adding consumers does not remove that boundary. Within a FIFO batch from one group, if A completes, B fails, and C remains unprocessed, stop after B and return B and C as failed and unprocessed. Executing C early can produce effects in a different order. Also assess DLQ use: removing a problematic message can break the intended exact sequence. Document how the application handles that gap before permitting continuation.
Prepare recovery and evidence
A DLQ needs ownership, retention, alarms, and an analysis procedure. For standard queues, moving to a DLQ retains the original timestamp for expiration. If a message arrives after three days and DLQ retention is six, approximately three days remain without other operations. FIFO differs by resetting the timestamp on that move. Before redrive, confirm the cause, data validity, and available capacity. Preserve logical identity to reconcile uncertain effects. Begin at a controlled rate and observe outcomes and failures. Storing messages in a DLQ neither completes the work nor guarantees recovery after retention expires. Record how the operator verifies the business outcome.
A, B, and C belong to one FIFO group. If B fails after A completes, the partial response includes B and C; C remains unprocessed.
Common pitfalls
Adding renewal to the old deadline, deduplicating only by attributes, reporting successes as failures, or advancing same-group operations.
Related topics: Events and decoupling · Identity and permissions
Delivery, deduplication, ordering, and business effects have different boundaries that the design must connect explicitly.
Reference: Lambda SQS partial batch responses · SAA-C03