A Lambda function consumes Amazon SQS batches for permit enrichment, but one poison message must not block the rest of the fleet. What consumer pattern should be used?
Select an answer to reveal the explanation.
Short Explanation
Treat the bad apple alone—partial batch failure lets good permit messages finish while the poison one retries or lands in a DLQ. Tossing the whole crate or shutting the dock forever stalls the fleet for one rotten message.
Full Explanation
When a Lambda function consumes Amazon SQS batches for permit enrichment, enable partial batch failure reporting so only failed messages are retried while successful ones are deleted. That isolates a poison message instead of replaying the entire batch and stalling enrichment for the fleet. Combined with a dead-letter queue, bad permits can be quarantined for analysis without blocking good ones.
Disabling the DLQ and infinitely retrying the entire batch whenever any single message fails fails by concept because one poison item repeatedly reprocesses healthy messages and amplifies load. Stopping the Lambda event source mapping permanently after the first error fails because it halts all municipal enrichment to “protect” downstream systems—an availability anti-pattern. Acknowledging and deleting the whole batch before processing fails because poison messages vanish without retry or visibility, causing silent data loss.
Exam caveat: SQS + Lambda batch consumers → partial batch failure responses (and DLQs). Whole-batch retry forever, shutting off the event source, or delete-before-process are wrong isolation patterns.
Operational check: Confirm the function returns the batchItemFailures structure correctly, successful message IDs are not redelivered, DLQ depth is alarmed, and poison payloads can be inspected. If one bad permit rewinds fifty good ones every time, partial failure reporting is not working.