The Code Pattern That Keeps Our Integrations Stable in Production

Dhruvi — Thu, 23 Apr 2026 16:31:30 +0000

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:

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:

2. Multi-step flows
Most integrations don’t stop at one system.

You might:

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:

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.

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.