HN Explorer

Show HN: Ayder – HTTP-native durable event log written in C (curl as client) (github.com)

56 points by Aydarbek ↗ HN
Hi HN,

I built Ayder — a single-binary, HTTP-native durable event log written in C. The wedge is simple: curl is the client (no JVM, no ZooKeeper, no thick client libs).

There’s a 2-minute demo that starts with an unclean SIGKILL, then restarts and verifies offsets + data are still there.

Numbers (3-node Raft, real network, sync-majority writes, 64B payload): ~50K msg/s sustained (wrk2 @ 50K req/s), client P99 ~3.46ms. Crash recovery after SIGKILL is ~40–50s with ~8M offsets.

Repo link has the video, benchmarks, and quick start. I’m looking for a few early design partners (any event ingestion/streaming workload).

11 comments

[ 3.2 ms ] story [ 31.8 ms ] thread
Aydarbek
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.

heipei
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.
tontinton
Very cool, have you taken a look into what TigerBeetle does with VSR (and why they chose it instead of raft)?
BrouteMinou
That's really interesting, I am even more eager to arrive at home to check that out.

Thank you for sharing this with us.

roywiggins
> 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?

mgaunard
Are those performance measurements meant be impressive? Seems on par with something threwn around with Python in 5 minutes.
apitman
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?
ghxst
If you go http native, could you leverage range headers for offsets?
Aydarbek
Yes, that maps quite naturally.

Classic HTTP Range is byte-oriented, but custom range units (e.g. `Range: offsets=…`) or using `Link` headers for pagination both fit log semantics well.

I kept the initial API explicit (`offset` / `limit`) to stay obvious for curl users, but offset-range via headers is something I want to experiment with, especially if it helps generic tooling.

dagss
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.

Aydarbek
This resonates a lot.

I’d love a world where “consume an event log” is a standard protocol and client-side tooling doesn’t care which broker is behind it.

Feed API is very close to the mental model I’d want: stable offsets, paging, resumability, and explicit semantics over HTTP. Ayder’s current wedge is keeping the surface area minimal and obvious (curl-first), but long-term I’d much rather converge toward a shared model than invent yet another bespoke API.

If you’re open to it, I’d be very curious what parts of Feed API were hardest to standardize in practice and where you felt the tradeoffs landed in real systems.