Thanks! We’re getting closer to production readiness so hopefully it’ll be useful soon.

Even after all of my searching I hadn’t seen zraft so I’ll have to look into it more. One of the design characteristics that I wanted was a backend that used an established database engine instead of handling files directly. Thats why our implementation uses rocksdb (although since its pluggable you could really use whatever you want). Based on a quick glance at zraft it looks like its managing the log file directly. That doesn’t mean that its a poor implementation by any means. Just something I noticed and probably would have been a deal breaker for my uses. Hard to say though so I’ll have to dig in more.

Ra seems great but its under heavy development and is a sufficient departure from the original raft algorithm in regards to its failure detection that I felt better about building a solution that was a little closer to the original specification. Ra has made a bunch of tradeoffs that make total sense for its use in rabbitmq. Those are reasonable tradeoffs for them but aren’t tradeoffs that I need.

I actually think the work you are doing will be the enabler of killer apps for Elixir ecosystem especially in data processing pipelines. Among other things it will enable a Elixir native kafka like system that can expose a GenStage producer with no external dependencies on ZK. That would make Elixir the killer platform for data processing pipelines.