Idempotency and Exactly-Once Delivery

A trading system sends an order, the acknowledgment gets lost in transit, and the sender — not knowing whether the order actually executed — retries by sending it again. If the exchange executes both copies, you've now doubled a position by accident. True "exactly-once delivery," where every message is guaranteed to be processed exactly one time no matter what fails along the way, is provably impossible to guarantee over an unreliable network (the same result the Two Generals Problem demonstrates), so real systems solve a more tractable, adjacent problem instead: make the operation safe to repeat, so it doesn't matter if the same message arrives twice.

An operation is idempotent if applying it multiple times has the same effect as applying it once. "Set my position to 500 shares" is idempotent — running it twice still leaves you at 500. "Add 100 shares to my position" is not — running it twice adds 200. The fix for a non-idempotent operation like an order submission is usually to attach a unique client order ID to every message: the receiving system checks whether it has already processed that ID before acting on it, and if it has, it simply returns the previous result instead of executing again. This converts "at-least-once delivery, which is achievable" into "effectively-once processing," without needing the network itself to guarantee anything stronger than delivering a message at least once, possibly with retries.

This pattern — retry freely on the sending side, deduplicate by unique ID on the receiving side — is the standard building block underneath most reliable trading and data pipelines, since it sidesteps a networking problem that has no perfect solution by making the cost of imperfection (an occasional duplicate) harmless rather than trying to eliminate duplicates outright.