The duplicate send risk
Queues deliver at least once, producers retry, and workers crash mid send. Without protection a user could get the same message several times. Idempotency makes a repeated send produce the same single delivery.
Idempotency keys
The producer supplies a stable idempotency key per logical notification. The service records the key with its outcome:
- First time the key is seen, send and store the result.
- A repeat of the key returns the stored result without sending again.
The send race
The hard part is the gap between calling a provider and recording success. If the worker dies after the provider sends but before recording, a retry might resend. Solutions include provider side idempotency keys and writing an intent record before the call.
Practical guarantees
Most systems aim for effectively once by combining client keys, provider keys, and dedup windows, accepting that perfect exactly once is impossible across independent systems.
Key idea
Idempotency keys plus provider keys make repeated send requests deliver once, achieving effectively once across unreliable links.