Hi, Tim. We have a group notification service that handles cross-method escalation across in-app, sms, voice, and email. Right now, we treat actors more like executor services, not managing state at all. State today is maintained in the database. Well, that's not terribly scalable, and it's not terribly fast. We want both of those characteristics, and are willing to give up some of the C in the CAP theorem to get it, i.e., eventual consistency.
We're exploring moving to an event-sourced actor-per-aggregate-root approach where the entities' states are maintained in the actors themselves, and the database is relegated to simply backing up the actor. In this role, the database is used to persist events and state, which would only be used when "recovering" or foregrounding an actor. In the messaging space, for example, we might have one actor per conversation.
We wouldn't be pursuing CQRS at the moment, but this approach seems to set us up nicely for CQRS. We could have separate actors that consume the same events, effectively creating different "projections" of the events, which can be leveraged for the Query part of CQRS. Akka PersistentViews could be used here.
This talk (
https://www.youtube.com/watch?v=2wSYcyWCtx4) by the Typesafe CTO gave me a bit more confidence to pursue this approach.