Let's Talk About idempotency

Edna112 — Tue, 21 Apr 2026 02:38:59 +0000

“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?

backend #systemdesign #architecture #softwareengineering #laravel

EVENTUAL INCONSISTENCY

Edna112 — Mon, 20 Apr 2026 11:08:43 +0000

The system didn’t crash. But two parts of it disagreed. Everything looked normal. Requests were fast. No errors, No alerts. Then something subtle happened. A user checked their data from two different endpoints.Same request. Different answers,outdated. Not random. Just… inconsistent.
The problem
The system wasn’t behaving like a single system. It was behaving like multiple independent parts.
What was happening?
In distributed systems:
There is no single source of truth at every moment.
Different services, replicas, or nodes…
Can see different versions of the same data.
So two parts of your system can both be Correct. But not aligned.
Why this is dangerous
Nothing fails.
Nothing crashes.
But your system starts to:
• contradict itself
• confuse users
• break trust
And the worst part?
It’s working exactly as designed.
The solution
You don’t assume consistency.
You define it.
Real systems make explicit choices:
• Decide where strong consistency is required
• Accept temporary inconsistency where it’s safe
• Design flows that tolerate delayed synchronization
• Ensure critical paths never rely on conflicting data
Mental model
Think of a team without synchronization. Everyone is working. Everyone is doing their job. But without alignment…They produce conflicting results.
The lesson
Distributed systems don’t naturally agree.
Agreement is something you design.
Takeaway
A system isn’t reliable because it works.
It’s reliable because it stays consistent across its parts.

backend #systemdesign #architecture #softwareengineering #laravel

DEV Community: Edna112

Let's Talk About idempotency

backend #systemdesign #architecture #softwareengineering #laravel

EVENTUAL INCONSISTENCY

backend #systemdesign #architecture #softwareengineering #laravel