Anyone playing with or using Akka's Cluster Sharding

22 views
Skip to first unread message

Jason Law

unread,
Mar 18, 2015, 1:15:25 AM3/18/15
to uses...@googlegroups.com
Anyone using or playing with Akka's Cluster Sharding, or really any kind of event sourcing or CQRS with actors? I've been toying with it and am leaning toward implementing it for a thin slice, and if things go well, moving to it for a substantial part of a very fast, very scalable API. But of course I don't know what I don't know...

Tim Harper

unread,
Mar 18, 2015, 11:45:23 AM3/18/15
to uses...@googlegroups.com
I don't have a huge amount of experience with it, but booted up and played with it, used the file-store store for snapshotting / command store & default binary akka serialization. I was really, really impressed.

I don't have any practical use for it as of yet, but the CQRS / event-sourcing patterns are things of which I'm big fans.

Curious, if you can share, what is your use case? What problem are you hoping to solve with event-sourcing in actors?

On Mar 17, 2015, at 23:15, Jason Law <ja...@lawcasa.com> wrote:

Anyone using or playing with Akka's Cluster Sharding, or really any kind of event sourcing or CQRS with actors? I've been toying with it and am leaning toward implementing it for a thin slice, and if things go well, moving to it for a substantial part of a very fast, very scalable API. But of course I don't know what I don't know...

--
You received this message because you are subscribed to the Google Groups "Utah Scala Enthusiasts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to usescala+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jason Law

unread,
Mar 20, 2015, 11:54:42 AM3/20/15
to uses...@googlegroups.com
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.

Ryan K

unread,
Mar 21, 2015, 6:37:42 PM3/21/15
to uses...@googlegroups.com
I have used in production and it works great.  The biggest thing is that you use a journal plugin that can handle the write load.  The default just writes to leveldb which doesn't scale.  I am biassed but I really like cassandra because of it's ability to linearly scale:


The other thing to think about is how much state your actor has and is being saved.  When your cluster shard is rebalanced it could move actors to another server.  If it has a very large state this will cause problems.  It is better to keep the actor state to be fairly small.  
Reply all
Reply to author
Forward
0 new messages