Examkin

Question

Difficulty: HardServerless Development with AWS Lambda

A developer is implementing a logistics microservice using an AWS Lambda function to process shipment status updates. To ensure idempotency and prevent processing duplicate updates within a short timeframe, the developer initializes a mutable Set outside the handler function to store processed update IDs. During load testing, two issues are observed: concurrent invocations occasionally process duplicate updates, and subsequent sequential invocations reject valid updates. Which explanation accurately describes the root cause of these issues, and what is the recommended solution?

  1. A
    The Lambda execution context is shared across all concurrent executions but is completely destroyed immediately after a sequential execution finishes. The duplicates are caused by a race condition within the shared context, and the sequential failures are due to the Lambda function exceeding its default concurrency limit. The recommended solution is to enable Provisioned Concurrency.
  2. B
    The Lambda function is running in a private VPC subnet without a NAT Gateway, which prevents the global Set from communicating with the underlying AWS Lambda service state manager to synchronize across invocations. The recommended solution is to move the Lambda function to a public subnet or configure a NAT Gateway for internet access.
  3. Lambda reuses the execution context for sequential invocations, which preserves the global Set across executions and causes valid sequential updates to be rejected. However, concurrent invocations run in separate execution contexts, meaning they do not share the Set and can process duplicates. The recommended solution is to store the processed update IDs in Amazon DynamoDB and use conditional writes.Answer
  4. D
    The issue is caused by the Lambda function's execution timeout being set lower than the SQS visibility timeout, which causes the messages to be returned to the queue and processed multiple times concurrently while the global Set is cleared. The recommended solution is to increase the SQS visibility timeout to at least six times the Lambda function timeout.

Answer

The correct answer explains that Lambda reuses the execution context for sequential invocations, preserving the global state (the Set) and causing valid sequential updates to be rejected, while concurrent invocations run in separate execution contexts and do not share state, resulting in duplicates. The solution is to store the processed update IDs in Amazon DynamoDB and use conditional writes.
The correct answer identifies that AWS Lambda reuses the execution context (including the global memory state) for subsequent sequential requests, which causes the list of processed updates to persist and reject valid requests. For concurrent requests, separate execution contexts are initialized, which prevents them from sharing the in-memory Set and allows duplicate updates to proceed. Storing these IDs in an external, centralized datastore like Amazon DynamoDB using conditional writes solves both issues by ensuring atomic, shared state checks.

Step-by-Step Solution

1
Evaluate the AWS Lambda execution model and context reuse behavior.
Variables in the global scope (outside the handler) are preserved across sequential invocations that reuse the same execution context, but are isolated between separate concurrent executions.
Lambda optimizes performance by keeping the container warm for subsequent requests, but it does not share memory across concurrent containers.
2
Correlate the observed testing behaviors with the execution context lifecycle.
Sequential invocations reject valid updates because the Set retains IDs from previous runs. Concurrent invocations process duplicates because they run in isolated environments with empty Sets.
This explains why local in-memory caching is insufficient for global idempotency.
3
Identify the AWS best practice for distributed state and idempotency.
Using a persistent, shared datastore like Amazon DynamoDB with conditional writes allows checking and updating the state of an update ID atomically.
This ensures a single source of truth that is accessible by all concurrent Lambda containers.

Key Concept

AWS Lambda execution context reuse and stateless design patterns
Rate this question

Topics

Serverless Development with AWS Lambda

More questions from this topic