3

I currently like using redis with akka because I can then monitor what messages have been processed just by querying redis. Redis also persists to disk.

How does akka persistance compare to just using redis?

cool breeze
  • 4,461
  • 5
  • 38
  • 67

1 Answers1

4

I would say that neither option is better than the other, although the offer different things. Akka persistence is about persisting each event your actor handles, so that those events can be replayed to rebuild the state of your actor. It is an implementation of Event Sourcing http://martinfowler.com/eaaDev/EventSourcing.html. You can also interrogate the stored events for other purposes such as analytics about the behaviour of the system. Since every historical event is recorded, analytics can be detailed. http://www.cakesolutions.net/teamblogs/using-spark-to-analyse-akka-persistence-events-in-cassandra

Another persistence mechanism may only contain the current state of the system, so analytics over the history would not be possible.

Event Sourcing may not suit every application, quoting the Martin Fowler article:

Packaging up every change to an application as an event is an interface style that not everyone is comfortable with, and many find to be awkward. As a result it's not a natural choice and to use it means that you expect to get some form of return.

By using Redis (or any other database) directly, you have more complete control over the method of persistence. With Akka Persistence you are required to use its way of doing things, but some of the details are abstracted away from you. It is to some extent a trade off of flexibility (writing your own persistence layer e.g. using Redis) vs ease of use (using the Akka Persistence library).

Akka Persistence is pluggable in terms of which system is used for persistence. There are plugins for many storage systems, including Redis: https://github.com/hootsuite/akka-persistence-redis

So, one advantage of Akka Persistence is that you could change persistence layer (e.g between test and production, or from RDBMS to NoSQL as your applications needs change over time) without needing to change your application code.

mattinbits
  • 10,370
  • 1
  • 26
  • 35