Tagged idempotency
7 pieces
- · 10 min read
Accept Is Binding, So Accept Has To Be Idempotent
When a counterparty can accept an executable quote from a phone, the accept action will be repeated. A tap on poor signal that appears to do nothing gets tapped again, clients retry on timeout, and proxies replay. Unless an idempotency key is checked before the state transition is applied, the second attempt creates a second binding trade against someone who believes they agreed once.
- · 9 min read
Trust the Webhook, Not the Page: Why Payments Go Missing Between Three Systems That All Report Success
The site, the payment processor and your records each work correctly on their own, and the money that goes missing is lost in the gaps between them. Confirming on the landing page loses every payment where the browser never came back. The processor retries for up to three days, may deliver the same event twice, and guarantees no ordering, so the handler has to be idempotent and the state has to be derived from a ledger rather than incremented on arrival.
- · 9 min read
When You Automate the Gatekeeper Away, Every Check They Made By Eye Becomes a Rule You Have to Enforce
A platform that lets a counterparty accept a binding quote without a human looking at it has not removed the gate, it has moved it into code. Every check the trader used to perform by judgement now has to exist as an enforced rule, the binding action has to be idempotent, and the number the engine computes has to equal the number the human would have produced, to the cent. The rounding trap that makes a parity test agree with itself is the one that costs money.
- · 10 min read
Sync The Commercial Record From Day One, And Make The Sync Idempotent
When a platform transacts and a separate system holds the customer relationship, retro-fitting the sync between them costs far more than building it with the first transaction. The integration has to be idempotent from the start, because a duplicate contact or a duplicate deal is a commercial problem rather than a technical curiosity. Most of the work is deciding which system owns which fact, before any data moves.
- · 11 min read
OpenAPI Cannot Describe Your Events: Seven Things an Event Contract Must State
Request-response interface description formats cannot express an event-driven contract. There is no caller, there is no meaningful response, delivery is at-least-once, and ordering is not guaranteed. Teams document their events in a request-response format anyway, and the resulting document omits exactly the properties that cause incidents. Here are the seven things an event contract has to state, and how a unique index becomes the place the contract is actually enforced.
- · 8 min read
At Least Once With No Replay
Inbound webhooks from major messaging and social platforms retry over an extended window and typically offer no way to request message history afterwards. That pairing produces duplicates on one side and unrecoverable gaps on the other. Deduplicating on a stable identifier and recording every receipt has to be built on day one, because an outage longer than the retry window is a permanent data loss.
- · 6 min read
Exactly-Once in Effect Is Not Exactly-Once, and the Difference Is Where Your Ledger Stops
Deduplicating on an event identifier and deriving state from an append-only ledger gives you exactly-once behaviour over an at-least-once unordered stream. That is the strongest thing available and it rests on one assumption: that the identifier is a sound deduplication key. Name the assumption, because the cases where it fails are real and the backstop is reconciliation rather than the handler.