Hi Prakhyat, We are building a CQRS/DDD-oriented configuration system based on akka persistence and are running into the same modeling issues. A few characteristics of our specific case:
1) We do not expect a high volume of commands to be submitted (they are generated via a task-based user interface that will have on the order of 30-50 users). 2) We have a number of cases where the output events of one aggregate must eventually trigger a change on another aggregate. This use case is what I am referring to as 'sagas'. There are two concerns that need to be addressed: guarantee that the messages will eventually get delivered in the event of system error/failure and the ability of the receiving aggregates to be able to order/handle them. 3) We use the cassandra connector for akka persistence with a 'quorum' consistency level for writing and reading. Since we are not dealing with high throughputs, a less performant but a safer solution to addressing the concerns in (2) are possible for us without introducing another system to an already complicated infrastructure. We can have the aggregates that may receive events from others reliably query the views for the aggregates they depend on (reading from Cassandra) directly to ensure messages are not missed and come in order. In our view, putting the weight on the consumer to deal with out of order messaging was painful for us. I've read the blogs arguing for being able to deal with this, but it just felt like something the framework should handle for you in the end. The reliable, in-order messaging concern also extends to 'stream consumers' in general. For this, we are looking at building a service that reads from all views (ordering across processors/aggregates by timestamp), assigns a 'global' sequence number to the event, and persists this in a stream. We then can have our consumers read from this stream with confidence that events will arrive in order and not be missing. That service could run as a singleton in an akka cluster for reliability - performance is not a concern for us at our expected traffic. Both of the cases, highlight the need to have a reliable messaging integration to avoid the hoops we will be jumping through. On Sun, Aug 10, 2014 at 10:29 AM, Prakhyat Mallikarjun < [email protected]> wrote: > Hi Gary/akka team, > > I have requirement in my app that changes to one aggregate root affects > many more aggregate roots and all have to be in sync. I keep seeing in > discussions name of sagas being refered. Will really sagas help to resolve > this condition? Can I find any articles in this regard? > > Are there any other design approachs? > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: > https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to a topic in the > Google Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/SL5vEVW7aTo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
