How does Lambda handle failures and retries?

You have a Lambda triggered by an S3 upload that calls a third-party API. The API times out once. What does Lambda do next, and what should your code do to be safe?

A teammate asks why their SQS-triggered Lambda keeps processing the same message over and over. Walk them through what's happening and one code change to fix it.

Your async Lambda (invoked via EventBridge) starts failing intermittently due to a flaky downstream service. You see a spike in retries and the DLQ filling up. How do you tune the retry behavior without losing events, and what's the tradeoff of each knob?

You're debugging a Kinesis consumer Lambda where shard iterators are getting stuck. The logs show 'ThrottlingException' but concurrency isn't maxed. What's likely happening with retries, and how do you fix the backpressure?

Design a retry strategy for a payment-processing Lambda that must never double-charge. The function calls Stripe, then writes to DynamoDB. Where do you put idempotency keys, how do you handle partial failures, and what DLQ/Destination config ensures auditability?

Your team's Lambda fleet processes 50K events/min from SQS. A bad deploy introduces a bug that crashes on 5% of payloads. The retry storm takes down the downstream DB. How do you implement circuit-breaking at the Lambda level without AWS Step Functions?

You're migrating a legacy monolith to event-driven Lambdas. The old system had at-least-once delivery with manual deduplication. How do you architect the new retry/DLQ contracts across teams so downstream consumers can safely migrate without coordinated deploys?

A critical Lambda has a 0.1% poison-pill rate that blocks shards for hours. You can't fix the payloads upstream. Propose a multi-layer handling strategy (code, config, observability) that isolates bad records, preserves ordering for good ones, and gives on-call actionable alerts — without increasing latency for the 99.9%.