“The payment went through twice.”
That’s what my friend told me.
We were talking about a system he was building.Everything looked fine.
Payments were working. Users were happy. Until one day. Someone got charged twice. No crash,No error Just the same request…Processed twice.
The problem
In real systems, requests don’t always happen once.
They get:
• retried by the client
• resent after timeouts
• triggered twice by impatient users
The system didn’t understand that. So it did exactly what it was told.
Twice.
What was happening?
The system treated every request as new. It had no memory of what it had already processed. So when the same request came in again…It processed it again.
Why this is dangerous
Nothing breaks. Everything “works”.
But now you have:
• duplicate payments
• duplicate orders
• inconsistent data
And once money is involved… That’s a serious problem.
The solution
Design your system to be idempotent.
Meaning:
The same request can be sent multiple times…But only processed once.
Real systems do this by:
• attaching a unique request ID (idempotency key)
• storing processed requests
• rejecting or reusing previous results
So even if the request comes in twice…The outcome stays the same.
Mental model
Think of it like submitting a form with a reference number.
If you submit it again with the same number…
The system knows:
“I’ve already handled this.”
The lesson
In distributed systems, retries are normal.
Duplicate effects should not be.
Takeaway
Your system shouldn’t just handle success.
It should handle being asked to do the same thing… twice.
Have you ever seen a system charge twice or create duplicate data?
Top comments (0)