Design idempotent serverless handlers from the business operation

Duplicate delivery is normal in distributed systems. Lambda invocations can be retried, queues can redeliver, and callers can repeat a request after a timeout. The reliable question is not whether a duplicate will arrive; it is what business operation must happen only once.

Start with a stable key

Choose an idempotency key from the business action, not an execution detail. A payment intent, import batch, or customer command is more stable than a request timestamp or Lambda request ID. Store the accepted result beside that key and return it when the same action arrives again.

The record also needs an explicit in-progress state. That prevents two concurrent handlers from both deciding they are the first attempt. Define how long an incomplete record may live, how a failed attempt becomes retryable, and which downstream effects must be included in the same protection boundary.

Idempotency does not mean every operation is perfectly atomic. It means the system has a clear, observable answer when delivery happens again.