We’re developing an instance messaging platform and we’re using akka-persistence-cassandra to persist our data.
One of the problems we have is huge memory consumption due to too many running actors (of course, we have set the receive timeout to stop idle actors). The main reason behind the actors being up is that due to the nature of persistence actors, every time we want to persist an event, all of the events will be replied for the actor to restore it’s state, and it will wait until reaching receive timeout to stop itself. Also, this behavior leads to too many redundant read queries on Cassandra while the only thing we need to do is to write the new event.
So, we decided to find a solution to persist events without restoring the actor’s state. Is there any solution implemented in akka-persist to solve this problem or should we implement a solution? how do you propose we solve this problem?
Persisting an event without knowing the current state is dangerous in most cases. If you are sure it is safe you can override recovery in the PersistentActor to Recovery.none (https://doc.akka.io/docs/akka/2.5/persistence.html#recovery) or you snapshot to improve the recovery performance.
In general it is not so nice to revive a thread five months after it was active with a semi-related question. Better to open up a new discussion thread.
Probably the most important reason why you want that with event sourcing and CQRS is that the view is eventually consistent and you likely want to make business decision on commands based on consistent state. Another is that with the state in memory you can make those decisions much faster and skip a database roundtrip.
Usually decision will be made with part of state not all of them. It’s not good to consume a lot of memory. I think the right solution is to use cache only for that decision field. Another reason is that some of decision need aggregation, so the current state cannot help alone.