CQRS + Event Sourcing implementation using akka-persistence

Question

I want to use akka-persistence event sourcing feature in order to implement CRQS + Event Sourcing idea in my new project. The problem is that besides the documentation (http://doc.akka.io/docs/akka/snapshot/scala/persistence.html) I couldn't find any good examples or guidelines how to approach it. The documentation is great in terms of explaining all building blocks of the architecture like processors, views, channels but does not explain how to put them together.

So the question is: how I should connect a write model with read models in akka-persistence? I came up with three options:

• Direct connection EventsourcedProcessor -> View, the View receives all events directly from the journal. It seems the simplest solution, but I wonder if we can distribute processor and view on different nodes using this approach.

• EventsourcedProcessor -> Channel -> View/normal Actor. What is the difference with the first option? If this is the right solution, why we have Views in akka-persistence building blocks? Should I use Channels or PersistentChannels ?

• EventsourcedProcessor -> some kind of event bus (e.g. context.system.eventStream) -> Views/Actors.

What is the best way to go and why?

Gimlet

For an updated answer which makes use of Akka Persistence Query and Akka Streams, see https://mcmap.net/q/1011444/-how-to-approach-the-q-in-cqrs-when-doing-event-sourcing-with-akka – Thermopile

Answer 1

EventsourcedProcessor -> View is the way to do it. The view replays from the journal, so you need a distributed journal when placing the view on another machine. List of journal implementations can be found here: http://akka.io/community/

Chiaroscuro

Thanks! Could you explain why is that? It seems reasonable approach to cover all bad cases (e.g. node with a view restarts, asks for all events the journal and replays them) but I am a little afraid that it can hurt performance in the normal state of the cluster. I think that pushing events to some kind of event bus is more lightweight and distribution friendly than asking the journal for events all the time. Am I missing something in my understanding? Why have you chosen journal as a point of connection between processors and views? – Gimlet

There may be more efficient ways for specific use cases, but then you must consider things like: starting a new view, de-coupling between write and read sides, message loss, message ordering, duplicates. All these things can be hard problems in a distributed pub-sub architecture. – Chiaroscuro

Answer 2

I have also found it difficult to find any good examples on how to approach Akka Persistence and Event Sourcing. Therefore I have created this example application using Dropwizard and Akka Persistence, akka-persistence-java-example

This example uses PersistenceActor for writing data and PersistenceQuery for reading data.

Cowitch

Answer 3

Whilst I think reading from an EP's journal is a great way to recover / rebuild a View, it seems to be polling the journal (akka.persistence.view.auto-update-interval). This would not be appropriate if one wanted synchronous updates of the read model (which it has been suggested by some may be a good starting point for read models). I would suggest (and like to use myself) the journal for recovery but have some sort of pub-sub architecture for live events. I know this may be very hard but it seems like the right thing to do. However, I am not knowledgable enough to suggest how to do distributed pub-sub with Akka Persistence or other libraries or even sure if it is really practical to do it.

As an alternative, would it be possible for Views to be notified when journals they are following are updated?

Polysepalous

Answer 4

There is really nice discussion going on this topic. I am just pasting the conclusion post https://groups.google.com/forum/#!topic/akka-user/MNDc9cVG1To. Hope it should help readers landed in this post.

Lytton