3 ms·

Could you compare Liftbridge to Akka with persistence module and or streams? I'm looking for a lightweight, embeddable Kafkasque thing (esp interested in exactl

Could you compare Liftbridge to Akka with persistence module and or streams? I'm looking for a lightweight, embeddable Kafkasque thing (esp interested in exactly once delivery) that I can use to glue various services together.

tylertreat 7y ago
I'm not super familiar with Akka beyond high-level/actor model so I can't competently compare the two. NATS can be used to implement an actor model and has a similar philosophy to Akka core in terms of delivery semantics (i.e. no real guarantees - https://doc.akka.io/docs/akka/2.1/general/message-delivery-guarantees.html https://doc.akka.io/docs/akka/2.1/general/message-delivery-g...). 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-message-delivery https://www.lightbend.com/blog/how-akka-works-exactly-once-m...
kitd 7y ago
Not OP but you may find MQTT useful. http://mqtt.org/ http://mqtt.org/
- polskibus 7y ago
  Thanks, is there an option to make guaranteed delivery with MQTT?
  - kitd 7y ago
    What you want is the quality of service "QoS" flag set at connection time (edit: sorry, correction, publish time): https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901103 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.

tylertreat 7y ago

I'm not super familiar with Akka beyond high-level/actor model so I can't competently compare the two. NATS can be used to implement an actor model and has a similar philosophy to Akka core in terms of delivery semantics (i.e. no real guarantees - https://doc.akka.io/docs/akka/2.1/general/message-delivery-guarantees.html https://doc.akka.io/docs/akka/2.1/general/message-delivery-g...). 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-message-delivery https://www.lightbend.com/blog/how-akka-works-exactly-once-m...

kitd 7y ago

Not OP but you may find MQTT useful. http://mqtt.org/ http://mqtt.org/

polskibus 7y ago
Thanks, is there an option to make guaranteed delivery with MQTT?
- kitd 7y ago
  What you want is the quality of service "QoS" flag set at connection time (edit: sorry, correction, publish time): https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901103 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.