What are Lambda event source mappings?

The mapping is the consumer

For poll-based sources such as Amazon SQS, DynamoDB Streams, and Kinesis Data Streams, Lambda pollers retrieve records and invoke the target function. This differs from push-style services that directly invoke a function through its resource policy.

The source determines important semantics. Queues hide in-flight messages with a visibility timeout; streams retain ordered records in partitions or shards and allow multiple consumers to read them.

Balance batching, latency, and efficiency

Batch size and batching windows can reduce invocation overhead and improve throughput, but larger batches increase per-invocation work and can delay individual records. Payload limits can also cause a batch to contain fewer records than the configured maximum.

Make timeout, memory, visibility, and retry settings consistent with the slowest realistic batch. Load-test skewed record sizes and slow downstream calls rather than only uniform happy-path data.

Handle batch failures without replaying good work

A failed batch can be retried, and duplicate records can occur. Where supported, partial batch responses let the function report failed records so successfully processed records do not all need to return.

The handler must make each record idempotent and preserve ordering requirements. Poison records need a finite recovery path through age limits, retry limits, destinations, or a dead-letter queue appropriate to the source.

Control consumer scale and backpressure

Queue consumers can add pollers and concurrency as backlog grows, while stream concurrency is tied to shards or partitions and configured parallelization. Filtering can remove irrelevant events before they consume function capacity.

Set maximum concurrency or reserved concurrency when a downstream system cannot absorb the source's full rate. Watch iterator age or oldest-message age to distinguish healthy throughput from a growing recovery problem.