- Written in Go rather than Java/Scala (big benefit here IMO is getting a small static binary rather than having to run a JVM)
- Doesn't rely on Zookeeper
- Is integrated with NATS (can extend NATS with Kafka-like semantics, but in the future will allow for abstracting NATS away entirely)
- Uses gRPC for its API
- Supports "wildcard topics" - e.g. a stream can listen to the topic "foo.*" and will receive messages published on "foo.bar", "foo.baz", "foo.qux", etc.
- Allows for streams to be paused and subsequently resumed automatically when published to - on the roadmap is "auto-pausing" of sparsely used streams
- Exposes an activity stream that allows you to respond to events such as streams being created, deleted, paused, etc.
One advantage Kafka currently has is its consumer groups, which are on the roadmap for Liftbridge but not implemented yet.
There's a more complete comparison available here: https://liftbridge.io/docs/feature-comparison.html
Looking at Akka Streams, it appears to be more in line with Liftbridge, though I'm not totally sure. Liftbridge (like Kafka), is a message log, so messages do not get acked or removed from a stream (unless removed due to retention limits or compaction). I'm not sure if that's the case with Akka Streams.
I'm curious what your needs are around exactly-once delivery. From what I can tell, Akka only supports at-least-once semantics and is of the opinion that exactly-once isn't really possible as such (which is an opinion I agree with, but that's a more nuanced discussion). https://www.lightbend.com/blog/how-akka-works-exactly-once-m...
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.h...
Bear in mind that there are always limits in how guaranteed a "guaranteed delivery" actually is. "Exactly once" means that the broker has received it and the client has acknowledged that. What happens beyond the broker is outside the scope of the protocol and would have to be handled at the application level, eg using transaction ids, etc.
For instance, it sounds like it's a cluster-based distributed system for some clients to post messages and other clients to get notified about them through pattern matching on a standardized protocol, without any messages getting lost.