2

I am trying to understand when Akka is useful, with particular reference to the non-guaranteed nature of message delivery. From the Akka docs:

if you really need it [guaranteed delivery], most often you don't

The thing is, I can think of very few situations where loosing messages is acceptable. The only examples I have so far are:

  1. applications that service read only requests (because if messages are lost, the client can just retry).
  2. state is continually published in an idempotent way (dropped messages don't matter because the next one will be delivered shortly).

The first is a request response pattern so not really messaging, and the second again relates to a read only data stream of state, not messages which represent business events that must be acted on.

Furthermore, by claiming that guaranteed delivery is too expensive and always advocating "tell" rather than "ask", their philosophy seems to contradict the event sourcing model (clearly, guaranteed delivery is essential for event sourcing otherwise there is no deterministic view of the world).

So, the question: if you have a situation where ordered, guaranteed delivery is important (customer actions must be ordered per customer and obviously guaranteed) is Akka a good fit? Why not some other system that already has these semantics like a queue of some sort (Kafka, activemq etc)?

The Akka docs suggest that any additional guarantees should be built in on a per application basis. We have something similar at my work place (guaranteed messaging layer built on top of non-guaranteed delivery semantics) but this means that all of the application code interacts with this layer, so I don't see what benefit Akka provides over any other messaging system in this case.

I just find it really hard to believe that people don't care if messages are delivered or not, especially when talking about building credit card transaction processing systems and the like.

tonicsoft
  • 1,736
  • 9
  • 22
  • Possible duplicate of [Good use case for Akka](http://stackoverflow.com/questions/4493001/good-use-case-for-akka) (found with google of "what is Akka good for") – Clint Nov 27 '16 at 19:53
  • Neither the question you link to nor its accepted answer address the issue of guaranteed delivery at all, so I'm not sure it can be a duplicate of mine. – tonicsoft Nov 27 '16 at 19:59
  • The [Akka Docs](http://doc.akka.io/docs/akka/2.4.4/general/message-delivery-reliability.html#Discussion__Why_No_Guaranteed_Delivery_) link to this [Nobody needs reliable delivery](https://www.infoq.com/articles/no-reliable-messaging) – Clint Nov 27 '16 at 20:20
  • 2
    That's a great article, and makes things a little clearer. However, it's kind of amusing that the title is "nobody needs reliable delivery" and yet the article ends with an example of when reliable delivery is required (admittedly, at the business layer, not the transport layer). I guess I'm just sick of repeatedly implementing reliability at the business layer as all the apps in my system have the same requirements. Just felt like there should be library support for it, but maybe there isn't. – tonicsoft Nov 27 '16 at 23:19

0 Answers0