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.
I wish there was a standard protocol for consuming event logs, and that all the client side tooling for processing them didn't care what server was there.
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.
Love seeing this written in C with an organic, grass-fed Makefile. Any details on why you decided to go that route instead of using something with more hype?
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.
LLM tics like the bits I quoted feel more like marketingspeak by committee than an actual readme written by a human. I don't have any particular suggestions of what to write, but you just don't need to be this punchy in a readme. LLMs love this style though, for some reason.
When I read this type of prose it makes me feel like the author is more worried about trying to sell me something than just describing the project.
For instance, you don't need to tell me the numbers are "real". You just have to show me they're covering real-world use-cases, etc. LLMs love this sort of "telling not showing" where it's constantly saying "this is what I'm going to tell you, this is what I'm telling you, this is what I told you" structure. They do it within sections and then again at higher levels. They have, I think, been overindexed on "five-paragraph essays". They do it way more than most human writers do.
Totally fair, if this were “single-node HTTP handler on localhost”, then yeah, you can hit big numbers quickly in many stacks.
The point of these numbers is the envelope: 3-node consensus (Raft), real network (not loopback), and sync-majority writes (ACK after 2/3 replicas) plus the crash/recovery semantics (SIGKILL → restart → offsets/data still there).
If you have a quick Python setup that does majority-acked replication + fast crash recovery with similar measurements, I’d honestly love to compare apples-to-apples happy to share exact scripts/config and run the same test conditions.
Good NICs get data out in a microsecond or two. That's still off by quite the order of magnitude, but that could be up to the network topology in question.
Durable consensus means this is waiting for confirmed write to disk on a majority of nodes, it will always be much slower than the time it takes a NIC to put bits on the wire. That's the price of durability until someone figures out a more efficient way.
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.
Nice to see HTTP API for consuming events.
I wish there was a standard protocol for consuming event logs, and that all the client side tooling for processing them didn't care what server was there.
I was part of making this:
https://github.com/vippsas/feedapi-spec
https://github.com/vippsas/feedapi-spec/blob/main/SPEC.md
I hope some day there will be a widespread standard that looks something like this.
An ecosystem building on Kafka clients libraries with various non-Kafka servers would work fine too, but we didn't figure out how to easily do that.
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.
Love seeing this written in C with an organic, grass-fed Makefile. Any details on why you decided to go that route instead of using something with more hype?
That makefile could be made even simpler if it used the implicit rules that compile c files into object files!
If you go http native, could you leverage range headers for offsets?
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.
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.
> 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.
LLM tics like the bits I quoted feel more like marketingspeak by committee than an actual readme written by a human. I don't have any particular suggestions of what to write, but you just don't need to be this punchy in a readme. LLMs love this style though, for some reason.
When I read this type of prose it makes me feel like the author is more worried about trying to sell me something than just describing the project.
For instance, you don't need to tell me the numbers are "real". You just have to show me they're covering real-world use-cases, etc. LLMs love this sort of "telling not showing" where it's constantly saying "this is what I'm going to tell you, this is what I'm telling you, this is what I told you" structure. They do it within sections and then again at higher levels. They have, I think, been overindexed on "five-paragraph essays". They do it way more than most human writers do.
If I might ask without being offending: How much percentage of the actual code is written by AI?
Are those performance measurements meant be impressive? Seems on par with something threwn around with Python in 5 minutes.
Please don't be a jerk or put down others' work on HN. That's not the kind of site we're trying to be.
You're welcome to make your substantive points thoughtfully, of course.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/showhn.html
Pointing out facts is not being a jerk. If you don't want feedback, don't solicit it.
Also if you disapprove, modding down is enough, you don't need to start a meta-discussion thread, which is itself a discouraged practice.
Totally fair, if this were “single-node HTTP handler on localhost”, then yeah, you can hit big numbers quickly in many stacks.
The point of these numbers is the envelope: 3-node consensus (Raft), real network (not loopback), and sync-majority writes (ACK after 2/3 replicas) plus the crash/recovery semantics (SIGKILL → restart → offsets/data still there).
If you have a quick Python setup that does majority-acked replication + fast crash recovery with similar measurements, I’d honestly love to compare apples-to-apples happy to share exact scripts/config and run the same test conditions.
Good NICs get data out in a microsecond or two. That's still off by quite the order of magnitude, but that could be up to the network topology in question.
Durable consensus means this is waiting for confirmed write to disk on a majority of nodes, it will always be much slower than the time it takes a NIC to put bits on the wire. That's the price of durability until someone figures out a more efficient way.
A NVMe disk write is 20 microseconds.