Exactly-Once vs At-Least-Once

The stack chooses delivery semantics per topic; safety-critical commands get effectively-once via idempotency, telemetry tolerates at-least-once.

L4 · Orchestration — its place in the stack (left, click any layer) and its internal components (right). Telemetry rises; control descends.

The three honest options

Distributed messaging offers at-most-once (may lose), at-least-once (may duplicate), and exactly-once (neither, but expensive and never truly free). True end-to-end exactly-once across independent actuators is a fiction; what is achievable is at-least-once delivery plus idempotent processing, which yields effectively-once state changes. Layer 4 states its choice explicitly per topic.

Topic class	Delivery	Effect
diagnostics	at-least-once	dedup on ingest
twin inputs	at-least-once	dedup by step key
commands	at-least-once + idempotent	effectively-once actuation
audit	at-least-once	append; dedup by event_id

Why not at-most-once

At-most-once is banned for anything that matters. Losing a breeder command acknowledgement or a burner interlock event could leave a procedure believing an action succeeded when it did not. The stack prefers a duplicate it can detect over a loss it cannot.

Achieving effectively-once

text

1. producer writes with idempotency_key (at-least-once)
2. consumer dedups on key within window
3. consumer processes and commits offset ATOMICALLY with its state
   (transactional outbox / read-process-write in one txn)
4. crash before commit -> reprocess -> dedup absorbs the duplicate

Step 3 is the subtle one: the offset commit and the state change must be atomic, or a crash between them re-processes an event whose effect already landed. The transactional outbox pattern makes this atomic without a distributed transaction on the hot path.

On the machines

A burner plug-field setpoint may be delivered twice under retry; because the command handler is idempotent (same key, same setpoint hash), the magnet is driven to the target once. A breeder gas-puff command uses the same discipline so a network hiccup cannot double-dose the fuelling. See idempotency.

The honest limit

Effectively-once is a property of state changes, not of side effects in the physical world. Once an actuator has moved, no delivery guarantee un-moves it; the guarantee is that orchestration will not ask it to move twice for one decision. That is why the strongest safeguard against double-actuation is not the messaging layer at all but the single-writer token and single-use idempotency key at the actuator adapter. The stack states its delivery semantics per topic precisely so no engineer mistakes at-least-once telemetry for a guarantee that a command cannot be re-issued, or mistakes idempotent handling for a promise that the physical world is transactional.