When you connect real systems - ERPs, APIs, AI workflows - things don’t behave cleanly.
Requests retry.
Webhooks get sent twice.
Sometimes something succeeds, but you don’t get the response.
And then you see it:
- duplicate orders
- repeated emails
- workflows triggering twice
This is normal in production.
The pattern that keeps this under control is idempotency.
The rule
Every action should be safe to run more than once.
Same input → same result.
If the same request hits your system twice, nothing should break and nothing extra should happen.
Where things usually go wrong
1. Partial execution
Something starts, then crashes halfway.
A retry comes in and runs everything again.
If you’re not careful, you create duplicates.
So instead of “just create”, you always check:
- does this already exist?
- should I update instead?
2. Multi-step flows
Most integrations don’t stop at one system.
You might:
- create something in one system
- then send it to another
If it fails in the middle, the retry should continue from where it stopped - not start from zero.
3. Side effects
This is where it gets visible.
Things like:
- sending emails
- charging payments
- triggering automations
If these run twice, users notice immediately.
So you need to control when they run and make sure they don’t fire again on retries.
What changed for me
I stopped assuming things run once.
Now I assume:
everything can retry
everything can duplicate
things can fail halfway
So the question is always:
what happens if this runs again?
In systems that run all the time, this isn’t an edge case.
This is how the system behaves every day.
And once you build with that in mind, a lot of production issues just stop showing up.
Top comments (0)