Exactly Once: The Engineering of Safe Execution

Between a strategy’s intent and a real fill sits a network — and networks crash, time out, retry, and reconnect. A naive system that resends after a timeout can place the same order twice. In a live market, that is not a glitch; it is real money.

This is one of the oldest hard problems in computer science. Ordering events across an unreliable distributed system is provably subtle^[1], and decades of transaction-processing theory exist to get it right^[2].

Idempotency is the answer

The discipline is simple to state and easy to get wrong: make every operation idempotent. Tag each order with a unique key; the router commits it at most once; any retry carrying the same key is recognised and ignored^[3]. Restarts replay safely because the system can always tell what it has already done.

Correctness is not a feature you add later. It is the architecture, or it is nothing.

Fail-closed and append-only

Two more principles complete the picture. Fail-closed: when state is uncertain, stop rather than guess. Append-only audit: every order and state change is written to a log that cannot be quietly rewritten.

Niro’s router is idempotent and risk-gated; a persisted cursor and an at-most-once claim mean restarts never double-apply, and every action lands in an append-only audit trail. The strategy is the interesting part; the plumbing is where money is actually lost or protected.