AWS / Intermediate: application service contracts / Lesson 8
Lambda invocation and concurrency
Choose invocation, retry, identity, network, and capacity contracts for event-driven compute without assuming exactly-once business execution.
On this page
Lesson goals
- Explain the assumptions, responsibilities, and trade-offs of lambda invocation and concurrency.
- Interpret both examples and distinguish declared intent from verified evidence.
- Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.
A function is one execution boundary
AWS Lambda runs code under a configured runtime, memory and execution settings, role, event integration, and service limits. It does not remove the need for application design or operational ownership. Supported runtimes, architectures, package types, extensions, and Regional features evolve, so select and verify them at release time. This course’s Python code is an offline logic simulation, not a deployed Lambda handler or a claim about a currently supported Lambda runtime version. Separate initialization, invocation, external dependencies, and durable state. Execution-environment reuse can improve performance but is not a guarantee that local memory survives or is unique.
Name the invocation and retry source
Synchronous invocation, asynchronous invocation, and event source mappings have different acknowledgment, retry, ordering, and failure behavior. The invoker may also retry independently. A timeout can leave uncertainty about whether the function already performed an external effect. The first synthetic record names a queue-based consumer and explicit retry ownership instead of saying Lambda always retries the same way. Read the current service-specific integration rules, batch behavior, visibility or retention settings, and failure destinations. Duplicate delivery or repeated processing must be tolerated where the chosen contract permits it; an application transaction is not made exactly once by selecting serverless compute.
invocation_contract: queue-event-source-mapping
operation_identity: application-defined-stable-id
retry_owner: documented-queue-and-integration-policy
partial_batch_behavior: explicitly-reviewed
failure_destination: approved-recovery-workflow
external_effects: idempotent-or-reconciled
The record is provider-neutral review metadata, not a Lambda configuration or a claim that every event source shares one retry policy.
Bound concurrency and dependency load
Concurrency counts overlapping executions rather than requests per second alone. Reserved concurrency can both bound a function and reserve capacity within the relevant account limits; provisioned concurrency addresses prepared execution capacity and has its own configuration and cost implications. Neither makes a database or upstream quota unlimited. Initialization, invocation duration, retry volume, and event backlog influence demand. Keep a maximum consistent with downstream connection budgets and service quotas. The second simulation shows only sequential duplicate suppression with synthetic identifiers; it deliberately provides no capacity recommendation or guarantee under parallel execution or process loss.
saved = {}
def handle(operation_id):
if operation_id not in saved:
saved[operation_id] = "lab-result-" + str(len(saved) + 1)
return saved[operation_id]
print(handle("lab-event-a"), handle("lab-event-a"))
print(len(saved))
lab-result-1 lab-result-1
1The repeated synthetic ID returns one in-memory result. This is not a durable or concurrent implementation and does not call Lambda or any persistence service.
Review execution role and network path separately
The execution role grants selected AWS actions; it does not by itself create a network path to a private database. VPC attachment, subnets, routes, security groups, endpoints, DNS, and dependency authentication have separate roles. Attaching a function to a public subnet does not automatically give its execution environment public internet access. Use the current Lambda VPC documentation for the chosen design. Keep credentials in an approved channel, reuse clients carefully, and avoid logging complete events or environment variables. A successful invocation can still return an invalid business result or hide a failed downstream write.
Verify durable outcomes and failure handling
Production idempotency needs a durable, atomic association between operation identity, accepted work, and outcome, with a defined retention and conflict policy. A global dictionary in one execution environment is not sufficient. Test malformed events, duplicate delivery, partial batch failure, timeout uncertainty, dependency outage, and recovery in an authorized isolated environment. Record safe request and deployment references while protecting event data. No function, event source mapping, IAM role, concurrency setting, VPC attachment, SDK call, or AWS invocation is created or executed here. Offline logic verifies one idea only; service integration and scale remain untested and must never be claimed from that simulation.
Common errors and fixes
Every Lambda failure is assigned one retry rule
- Why it happens
- Invocation source and integration semantics were ignored.
- How to fix it
- Read the exact invoker and event-source contract.
- Prevent it next time
- Record retry and failure ownership per integration.
A global variable is used as permanent deduplication
- Why it happens
- Execution reuse was confused with durable shared state.
- How to fix it
- Use an atomic durable idempotency design.
- Prevent it next time
- Test concurrent attempts and environment loss.
A public subnet is assumed to provide internet access
- Why it happens
- Lambda VPC network behavior was not reviewed.
- How to fix it
- Inspect the documented route, endpoint, and egress design.
- Prevent it next time
- Separate execution permission and connectivity tests.
Check your understanding
1. A function times out after asking an external payment API to charge. Is retry automatically safe?
Show worked solution
No. The remote operation may already have succeeded. Use an approved idempotency key or reconcile the remote result before repeating the effect. Timeout means the caller lacks a timely result, not that all downstream work was rolled back.
2. Why can a lower concurrency cap improve a serverless application’s reliability?
Show worked solution
It can protect a constrained database or upstream service from excessive parallel calls, allowing bounded backlog and recovery. Choose the value from actual dependency and latency requirements, and verify retry and queue behavior rather than assuming more parallelism always increases useful throughput.
Key takeaways
- AWS Lambda runs code under a configured runtime, memory and execution settings, role, event integration, and service limits.
- Concurrency counts overlapping executions rather than requests per second alone.
- Production idempotency needs a durable, atomic association between operation identity, accepted work, and outcome, with a defined retention and conflict policy.