The Cost of a Double-Send

"A duplicate isn't just a wasted request. It's a second, wrong turn wedged into a log that was supposed to be the truth."

Why 'Just Resend' Feels Free (But Isn't)

The reason careless retry is so common is that a double-send usually looks harmless in a demo: the answer shows up, the user is happy, nobody notices the duplicate. The costs are real but deferred and out of sight — which is exactly the kind of cost that accumulates unchecked. Line them up and "just resend" stops looking free:

Duplicated conversation turns. The same question lands twice in the canonical log. Now the conversation history has a phantom repeat that every future context replay carries forward.
Double model spend. Each duplicate that reaches the model is a second full inference — real compute, real cost, for an answer the user already had.
Confusing UX. Two answers to one question, possibly slightly different, force the user to wonder which is real. The client's job was to reduce doubt, not manufacture it.
Corrupted ground truth. When the canonical log is the source of truth, a duplicate turn isn't a cosmetic glitch — it's the truth itself being wrong, and every derived view inherits the error.

The Log Is Sacred; Duplicates Desecrate It

In a system where an append-only log is ground truth, integrity of that log is everything. Downstream databases, search indexes, and UI are all rebuilt from it, so a duplicate written once propagates everywhere and is painful to unwind — you can't cleanly "un-ask" a question that history now records twice. This is why idempotent retry isn't a nice-to-have optimization. It's a guardian of the log's integrity. The dedupe key and the pre-call check exist so that no flaky-network artifact can ever become a permanent falsehood in the record.

Cheap Insurance Against Expensive Corruption

Weigh the two sides. The cost of idempotency is a UUID and a state check — a few lines, run once per turn. The cost of skipping it is duplicated history, wasted inference, user confusion, and a corrupted source of truth that's expensive to repair. That lopsided trade is why the discipline is non-negotiable for any client that writes into a canonical record. You're not optimizing a request; you're refusing to let an unreliable link corrupt the truth.

Code

One careless retry, four downstream costs·text

careless retry of turn X (ack was lost)
        |
        v
  +-----------------------------+
  | canonical log: X, X   <-- duplicated turn (ground truth now wrong)
  | model:        2x inference  <-- double spend
  | UI:           2 answers     <-- which one is real?
  | derived DBs:  rebuilt w/ X,X <-- error propagates everywhere
  +-----------------------------+

// The dedupe key + pre-call check collapse the retry back to a single X.
// Idempotency isn't an optimization here; it's log integrity.

Exercise

For a client that writes into an append-only canonical log, enumerate every cost of a single duplicated turn: in the log, in compute, in UX, and in every view derived from the log. Then estimate the cost of the idempotency machinery that prevents it (a UUID + a state check). Write the two columns side by side. The imbalance is the argument for why this discipline is never optional.

Hint

The prevention cost is fixed and tiny; the corruption cost is variable, compounding, and lands in the one place you can least afford it — the source of truth. Any time prevention is a few lines and the failure corrupts ground truth, prevention wins decisively.