Idempotency
Problem
- An Azure SQL Agent job runs daily at 1 PM. It sends order confirmation emails via SendGrid.
- One day, by mistake, the same job gets triggered again at 2 PM.
- The job walks the same orders again and sends the same emails again. Every customer gets a duplicate confirmation.
A repeat run repeats every side effect.
Solution
Idempotency
- Record what has already been done: the job sets a NotificationSent flag per order after sending.
- Check before acting: each run skips any order whose flag is already set.
- The repeat run finds every flag set and does nothing.
The repeat call is not prevented; it is made harmless. That property, being safe to run again, is what makes an operation idempotent.
Run it once or run it five times, the system ends up in the same state.
Analogy
Pressing lock on your car key five times doesn't lock the car five times. The first press locks it; every extra press finds it already locked and changes nothing.
An idempotent operation works like that lock button.
