How do event delivery and idempotency work in serverless systems?

Treat duplicate delivery as normal recovery

A consumer can complete its side effect and fail before the source records success. The source cannot safely assume completion, so it delivers the message again. Networks, timeouts, batch retries, producer retries, and failover create similar ambiguity.

Exactly-once language often describes a bounded service feature, not an end-to-end business guarantee. Verify the complete path from producer through every side effect before relying on it.

Choose a stable idempotency key

Use an identifier for the logical business operation, not a delivery attempt. A payment request, order command, file version, or source event identifier can work when its uniqueness scope and retention are defined.

Store the key with status, result, and expiration in a strongly consistent operation when possible. Two concurrent duplicate attempts must not both pass a check-then-write race.

Make every side effect safe

Database writes can use conditional operations or transactions. External APIs may support their own idempotency key. If an irreversible dependency has no such control, isolate it behind a record of intent and a recovery process.

Returning an earlier successful result can make synchronous retries transparent. For asynchronous work, record enough outcome information to distinguish completed, in-progress, retryable, and permanently failed operations.

Separate deduplication from ordering

Removing duplicates does not ensure events are processed in order, and ordering does not prevent duplicate attempts. Define the entity or message group that needs order and how late or stale events are recognized.

Use version numbers, sequence values, conditional writes, or state-machine rules when an older event must not overwrite newer state. Test concurrent delivery and replay, not only consecutive duplicates.