Events, retries, and idempotency | AWS Developer Associate: applications and operations

Concept and mechanism

Receiving a message is not the same as completing a business operation. When Lambda processes standard SQS, the application must tolerate delivery of the same work again. Use a stable operation identity and durable state distinguishing pending, completed, and uncertain outcomes. Storing only an invocation ID does not recognize a new attempt. Within a batch, one failure can also repeat successful items. Partial responses require event source mapping configuration and a handler returning failed identifiers according to the contract. Idempotency remains necessary because reducing retries does not guarantee exactly-once execution.

Guided application

In a fictional banking integration, a timeout after submitting an instruction may mean the target accepted it but the response was lost. Query status or use the supported idempotency contract before resubmitting. For transient failures, combine bounded attempts and backoff with the overall deadline; the SDK may already retry. A circuit breaker limits pressure on a degraded dependency and probes recovery in a controlled way. EventBridge routes events through patterns: rehearse matches and nonmatches. When reusing a Lambda environment, retain reusable SDK clients but separate user and request data to prevent cross-invocation contamination.

IN PRACTICE

In a standard batch with A and C completed and B invalid, return only B as failed when partial responses are enabled. An unhandled handler exception still represents batch failure.

Common pitfalls

Retrying without a deadline; acknowledging invalid messages; assuming FIFO removes every duplicate effect; storing customer state globally.

Related topics: Data, concurrency, and pagination · Identities and resource authorization

Take this idea with you

Separate delivery, execution, and confirmation of the business effect.

Create account

Reference: Lambda with SQS · DVA-C02; exam guide 2.1