The demo intentionally starts with SIGKILL to show crash recovery first.
For benchmarks: I used real network (not loopback) and sync-majority writes in a 3-node Raft cluster.
Happy to answer questions about tradeoffs vs Kafka / Redis Streams and what’s still missing.
Yes I’ve read through TigerBeetle’s VSR design and their rationale for not using Raft.
VSR makes a lot of sense for their problem space: fixed schema, deterministic state machine,
and a very tight control over replication + execution order.
Ayder has a different set of constraints:
- append-only logs with streaming semantics
- dynamic topics / partitions
- external clients producing arbitrary payloads over HTTP
Raft here is a pragmatic choice: it’s well understood, easier to reason about for operators,
and fits the “easy to try, easy to operate” goal of the system.
That said, I think VSR is a great example of what’s possible when you fully own the problem
and can specialize aggressively. Definitely a project I’ve learned from.
Thank you for sharing, this looks really cool. The simplicity of setting this up and operating it reminds me a lot of nsq which received a lot less publicity than it should have.
That’s a great comparison nsq is a project I have a lot of respect for.
I think there’s a similar philosophy around simplicity and operator experience.
Where Ayder diverges is in durability and recovery semantics nsq intentionally
trades some of that off to stay lightweight.
The goal here is to keep the “easy to run” feeling, but with stronger guarantees
around crash recovery and replication.
The demo intentionally starts with SIGKILL to show crash recovery first.
For benchmarks: I used real network (not loopback) and sync-majority writes in a 3-node Raft cluster. Happy to answer questions about tradeoffs vs Kafka / Redis Streams and what’s still missing.
Very cool, have you taken a look into what TigerBeetle does with VSR (and why they chose it instead of raft)?
Yes I’ve read through TigerBeetle’s VSR design and their rationale for not using Raft.
VSR makes a lot of sense for their problem space: fixed schema, deterministic state machine, and a very tight control over replication + execution order.
Ayder has a different set of constraints: - append-only logs with streaming semantics - dynamic topics / partitions - external clients producing arbitrary payloads over HTTP
Raft here is a pragmatic choice: it’s well understood, easier to reason about for operators, and fits the “easy to try, easy to operate” goal of the system.
That said, I think VSR is a great example of what’s possible when you fully own the problem and can specialize aggressively. Definitely a project I’ve learned from.
> No manual intervention. No partition reassignment. No ISR drama.
> Numbers are real, not marketing.
I'm not questioning the actual benchmarks or anything, but this README is substantially AI generated, yeah?
Fair question.
The benchmarks, logs, scripts, and recovery scenarios are all real and hand-run that’s the part I care most about being correct.
For the README text itself: I did iterate on wording and structure (including tooling), but the system, measurements, and tradeoffs are mine.
If any part reads unclear or misleading, I’m very open to tightening it up. Happy to clarify specifics.
That's really interesting, I am even more eager to arrive at home to check that out.
Thank you for sharing this with us.
Thanks! If you hit any rough edges getting it running, tell me I’ll fix the docs/scripts.
Thank you for sharing, this looks really cool. The simplicity of setting this up and operating it reminds me a lot of nsq which received a lot less publicity than it should have.
That’s a great comparison nsq is a project I have a lot of respect for.
I think there’s a similar philosophy around simplicity and operator experience. Where Ayder diverges is in durability and recovery semantics nsq intentionally trades some of that off to stay lightweight.
The goal here is to keep the “easy to run” feeling, but with stronger guarantees around crash recovery and replication.