An engineering deep dive into API retries, idempotency keys, PostgreSQL concurrency, and the failure that happens between two systems.

You order something online, enter your card details, and click Pay .

Five seconds later, the page gives up. No receipt. No confirmation. Just a timeout and a button that says Try again .

There are two possibilities. The payment never happened, or it happened and the confirmation didn't get back to you. From where you're sitting, both look exactly the same.

That small uncertainty has an uncomfortable consequence: clicking Try again could be the correct way to finish your purchase, or the beginning of a second charge.

I started looking into idempotency because I wanted to understand how real backend systems deal with this. At first, the solution sounded almost trivial: give every payment a unique ID and remember it. That description is technically useful, but it hides the hard questions. What if two requests arrive together?…