Delivery Is At-Least-Once; Intent Is Exactly-Once

"You can't make the network deliver exactly once. You can make the same delivery, arriving twice, mean the same thing once."

The Uncomfortable Truth About Networks

Here's a fact every resilient client eventually confronts: you cannot get exactly-once delivery over an unreliable network. It's not a matter of trying harder. Consider the classic trap — your request reaches the backend, the backend processes it, and then the response gets dropped on the way back. From the phone's view, the request "failed." But it didn't; only the acknowledgment was lost. If the client now retries, the backend sees the same request a second time. Delivery is at-least-once: a message may arrive zero times, once, or several times, and the client genuinely cannot tell the difference from the outside.

Move the Guarantee Up a Layer

Since you can't fix delivery, you fix meaning. The goal isn't exactly-once delivery (impossible); it's exactly-once intent — no matter how many times a request physically arrives, it has the effect of one. That's what idempotency buys: an operation you can apply repeatedly with the same result as applying it once. A retry becomes safe not because you guaranteed it won't repeat, but because a repeat is harmless.

Delivery layer: unreliable, at-least-once, out of your control. Accept it.
Intent layer: reliable, exactly-once, entirely in your control via a dedupe key. Build it.

This is the mental shift the whole track hangs on. Stop trying to prevent duplicates on the wire; start making duplicates not matter.

Why This Frees You to Retry Boldly

Once duplicates are harmless, retry stops being scary. You can resend on reconnect, resend on app launch, resend on a user tap — as often as reliability demands — because the intent layer collapses all those arrivals into one effect. A client that fears retrying tends to under-deliver (drop things to be safe); a client with idempotent intent can retry generously and still never double-act. The next lessons build the dedupe key that makes this real: the device turn ID.

Code

The dropped-ack trap that makes exactly-once delivery impossible·text

Phone                         Backend
  |  --- ask (turn X) ------->  |
  |                            |  processes X, answers
  |  X    response ----------  |   <-- dropped in transit
  |  (sees a failure)          |
  |  --- ask (turn X) again -> |   <-- same intent arrives twice
  |                            |  MUST recognize X, not redo it

// The phone can't distinguish 'request lost' from 'response lost.'
// So it retries. Only a dedupe key on turn X keeps the effect exactly-once.

Exercise

Describe, step by step, the dropped-acknowledgment scenario: request succeeds, response is lost, client retries. At each step, write what the phone believes and what the backend believes. Then explain why no amount of retrying or timeout-tuning on the phone alone can make delivery exactly-once — and what single mechanism (hint: a stable key) fixes it at the intent layer instead.

Hint

The phone and backend disagree precisely because the phone never learned the first attempt succeeded. Timeouts can't resolve that disagreement; only a shared dedupe key the backend can recognize on the second arrival can. That key is the device turn ID.