Exactly-once state recovery does not automatically commit the outside world

After failure, records following the restored checkpoint can run again. Correct recovery reconstructs their managed-state contributions without retaining both pre-failure and replayed versions. A sink that exposes each attempt immediately can still duplicate visible output even when internal state is restored correctly. Exactly-once output therefore needs a sink-specific mechanism, such as a compatible transaction or an idempotent identity-based update. State the unit being counted: a source log position, a business event ID, or a keyed aggregate version. Duplicate business events at different source positions are not automatically deduplicated by processing each position once.

Late corrections can legitimately produce several updates for one window, so exactly-once does not mean one output message for every conceptual result forever. It concerns the promised committed contribution or update semantics under recovery. An append-only consumer and an upsert consumer interpret repeated result keys differently. Verify that the sink contract matches the operator's output mode, including retractions and replacements. A technically transactional append of two distinct but semantically duplicate business requests still creates two requests unless another application invariant prevents it.

A checkpoint-coordinated transactional sink can prepare output, retain the information needed to commit it, and make it visible through a compatible completion protocol. Flink 2.1's sink interfaces separate writing and committables from committing. The destination must support the required transaction semantics, and recovery must resolve prepared work correctly. A commit acknowledgment can be lost after the destination commits; repeating a recovery action must not create a second distinct effect. Transaction identifiers, fencing or equivalent stale-writer protection, durability, and timeout behavior belong to the connector's actual correctness argument.

Kafka 4.0 describes atomically writing output records and consumer offsets within Kafka transactions, with read_committed consumers avoiding uncommitted and aborted transactional records. That guarantee covers the coordinated Kafka path under its configuration and failure rules. It does not automatically extend to a database, HTTP service, email system, or a consumer that exposes uncommitted records. Flink connector checkpoint coordination is another implementation path that must meet its documented prerequisites. Do not mix settings from different APIs and claim the combined words 'transaction' and 'checkpoint' prove an end-to-end guarantee.

Inject failure after prepare, after checkpoint completion, during destination commit, and after destination success but before the committer observes it. Restore without local caches and inspect both managed state and externally visible effects. Include transaction timeout and long recovery conditions; a prepared transaction expiring before recovery can break a simplistic success story. For destinations without compatible transactions, use a documented idempotent protocol, an outbox boundary, or a narrower guarantee. Report the limitation explicitly rather than treating a replayed API call as harmless because the operator state is exactly once.

The probability lab illustrates repeated successful attempts without deduplication. Reset, set BOTH p=0.5 and n=2, predict probability 0.25 for two successes, then Play or Step. Reset and re-set BOTH p=0.5 and n=4; predict probability 11/16 for more than one success. Edits retain t; playback highlights exact counts rather than sampling attempts. There is no sink, transaction, commit, or idempotency key. The point is that successful delivery opportunities can repeat; only the actual output protocol determines whether several successes create one effect or several.