One message fails in a ten-message Lambda batch. What should happen to the other nine?

Say it in 30 seconds

Say it like this (20-30 seconds)

Successful messages should finish without being retried because of their neighbour. MiniTickets catches failures per record and returns the failed SQS identifiers in batchItemFailures. The event source mapping enables ReportBatchItemFailures, so Lambda honours that result. Both code and configuration matter: without the setting, a normal return deletes failed messages too. An uncaught exception or function timeout can still retry undeleted work, so each consumer must remain safe to repeat.

The deeper answer

The email and ticket handlers process records sequentially and collect failures. Bad JSON, unsupported payloads and downstream service errors are failures for that record; they do not stop the loop from attempting the others.

The returned identifiers are the SQS record IDs, not the application booking IDs. Lambda needs the transport identifiers to decide which received messages to retain. A successful duplicate is omitted from the failure list so it can be deleted.

Partial reporting reduces repeated work but does not isolate execution time. The batch still shares one Lambda invocation timeout. A slow first record can consume time needed by later records, and a timeout prevents the function from returning its final failure list. In production I would tune batch size against worst-case processing time and downstream capacity, then watch duration, retries and queue age together.

Counter-questions

What if ReportBatchItemFailures is missing?

This handler normally returns an object rather than throwing. Lambda ignores that failure list without the mapping setting and treats the batch as successful, deleting failed records too.

Why catch validation errors?

A malformed message should retry according to policy and reach a DLQ for investigation. It must not silently count as success or prevent valid neighbouring records from being attempted.

Would parallel processing improve throughput?

Possibly, but it increases simultaneous downstream calls and duplicate races. Sequential processing is simpler here; concurrency should follow measured duration and service limits rather than batch size alone.

Where in MiniTickets

Read Lambda worker, then inspect the worker-lambda piece →.

apps/worker/src/batch.ts → handleBatch