Name the side effect before adding retries
Choose the exact operation that must happen once, even when execution happens more than once.
A retry repeats execution, not intent. If a job times out after an external service accepted the request, the worker may run again without knowing whether the first attempt succeeded.
Begin by naming the durable side effect: charge invoice 842 once, send lesson 3 once, or import source file 19 once. Build the idempotency key from that business identity, not from a random attempt ID.
Store or pass the same key on every retry. Then make the receiving boundary return the existing result when it sees that key again. This turns an uncertain retry into a safe lookup instead of a second effect.
A lesson email can use journey ID plus lesson ordinal as its delivery identity. Attempt 1 and attempt 2 then share one provider idempotency key.
Apply this nowWrite the sentence: this job may run many times, but this exact side effect must happen once. Turn the nouns in that sentence into the idempotency key.
Idempotency does not replace monitoring or reconciliation when an external provider cannot return a definitive result.