[HN Gopher] Show HN: Chr2 - consensus for side effects (exactly-...
       ___________________________________________________________________
        
       Show HN: Chr2 - consensus for side effects (exactly-once is a lie)
        
       Most consensus libraries (Raft, Paxos) treat the state machine as a
       pure black box. This is fine until your state machine needs to
       actually do something, like charge a credit card, fire a webhook,
       or send an email.  If a leader crashes after the side effect but
       before committing it, you get duplicates. This is my attempt at
       fixing this problem from first principles ish: build chr2 to make
       crash-safe side effects first-class citizens.  mechanism:
       Replicated Outbox: Side effects are stored as "pending" in
       replicated state. Only the leader executes them under a fencing
       token.  Durable Fencing: A manifest persists the highest view using
       atomic tmp+fsync+rename. This ensures a "zombie" leader can't wake
       up and double-execute stale effects.  Deterministic Context:
       Application code receives a deterministic RNG seed and block_time
       from the log, ensuring 1:1 state transitions during replay.  Strict
       WAL: Entries are CRC'd and hash chained. it is designed to prefer
       halting on mid-log corruption over guessing.  The Trade-offs: Side
       effects are intentionally at-least-once; "exactly-once" requires
       stable effect IDs for sink-side deduplication. It's a CP system
       safety over availability.  Repo: https://github.com/abokhalill/chr2
       if you've ever had "exactly once" collapse the first time a leader
       died mid flight, you know exactly why I built this.
        
       Author : yousef06
       Score  : 5 points
       Date   : 2026-01-11 20:50 UTC (2 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       ___________________________________________________________________
       (page generated 2026-01-11 23:00 UTC)