Exactly-Once Results in an AP System: Two-Phase Commit, Raft, and the Window You Can't Close
In a pull-based, available-under-partition system the same task deliberately runs more than once, so how does a result land exactly once? A two-phase staging commit copies a staged object into an identity-derived final key so duplicates collapse to one, a Raft-agreed decision fences split-brain, and the one irreducible side-effect window is made safe with an idempotency key rather than wished away.