Chr2
consensus for side effects (exactly-once is a lie)
Details
- External ID
- 46579900
- Source
- HN
- Company
- —
- Product
- Chr2
- Website domain
- github.com
- Launched
- Jan. 11, 2026
- Cohort
- —
- Upvotes
- 12
- Upvotes percentile
- 0.5586297760210803
- Tags
- —
- Fetched at
- Sept. 7, 2026, 9:25 p.m.
- Updated at
- Sept. 7, 2026, 9:25 p.m.
Description
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/chr2if you’ve ever had “exactly once” collapse the first time a leader died mid flight, you know exactly why I built this.
Enrichment
- Theme
- Codex monitoring and optimization tools
- Vertical
- —
- Function
- Data infrastructure
- Audience
- Developer
- AI stance
- Not AI
- Project type
- Hobby / open-source project
- Normalized one-liner
- consensus mechanism for side effects
- Manually corrected
- False
Could you build this?
No Designing distributed consensus systems that properly handle non-idempotent external side effects without two-phase commit flaws requires deep specialized knowledge in distributed systems theory.
What it would actually take: Requires building an atomic commit and consensus engine (likely written in Rust or Go) integrating distributed state machines with transactional outboxes, idempotency keys, and crash-recovery protocols. The core difficulty lies in formal verification (e.g., TLA+ specifications), edge-case network partitions, and partial-failure guarantees for non-rollbackable external side effects.
Discussion
No comments on this launch.
Competitors
Other products that read as similar to this one — 29 launches clear the similarity bar, closest 8 shown.
Attention rank: #15 of 30 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).
Launched 71 days after the earliest competitor.
- Quorum-free replicated state machine built atop S3 · hn · 2026-01-31 · 6 upvotes · similarity 0.41
- Kybernis · hn · 2026-03-05 · 6 upvotes · similarity 0.40
- genpark-swarm-state-checkpoint-rollback-engine-skill · github · 2026-09-26 · 7 upvotes · similarity 0.37
- genpark-swarm-state-checkpoint-rollback-engine-skill · github · 2026-09-26 · 7 upvotes · similarity 0.37
- Herd · hn · 2026-03-25 · 6 upvotes · similarity 0.37
- idempotency-shield · github · 2026-09-17 · 85 upvotes · similarity 0.36
- ccodex-rotate · github · 2026-09-20 · 138 upvotes · similarity 0.35
- axonpush · ph · 2026-09-11 · 2 upvotes · similarity 0.35
Other launches for this product
- No other launches for this product.