Lambda & Event-Driven Design

The Idea

Lambda runs your function in execution environments it creates on demand. A new one pays an init phase — load code, start the runtime, run your init code — the cold start; later requests can reuse it warm. Concurrency is the number of requests in flight. Reserved concurrency caps a function and guarantees it that much; provisioned concurrency keeps environments initialised ahead of time.

Real-World Example

Upload events go into an SQS queue. Lambda polls it and invokes the function with batches; failed messages reappear after the visibility timeout, and the queue's redrive policy moves repeat failures to a dead-letter queue.

The Tradeoff

A function times out after at most 15 minutes, and all functions in a Region share one concurrency quota — 1,000 by default (both as of September 2026). Long jobs and huge bursts need a design: a queue in front, or containers.

Hands-On

# illustrative — an SQS-triggered handler; the event source mapping must list
# "ReportBatchItemFailures" in its FunctionResponseTypes
def handler(event, context):
    failures = []
    for record in event["Records"]:
        try:
            resize(record["body"])  # your work
        except Exception:
            failures.append({"itemIdentifier": record["messageId"]})
    return {"batchItemFailures": failures}  # only these are retried

def handler(event, context):
    failures = []
    for record in event["Records"]:
        try:
            resize(record["body"])
        except Exception:
            failures.append({"itemIdentifier": record["___"]})
    return {"batchItemFailures": failures}

Sources

• Understanding the Lambda execution environment lifecycle — AWS Lambda Developer Guide
• Understanding Lambda function scaling — AWS Lambda Developer Guide
• Handling errors for an SQS event source in Lambda — AWS Lambda Developer Guide
• Lambda quotas — AWS Lambda Developer Guide