If I understand your question correctly, you would like to know if there are generic approaches that can be applied to the scenario “How do I query for entities based on some secondary attribute, and then send those actors a command?” The short answer is yes, there are techniques/patterns that people have devised and are supported by Akka out-of-the-box, but your solution will invariably depend on your context. I can hardly cover all, but I can give you some food for though - and then I shall try to unpack the example problem.
Generally accepted as the most appropriate approach, you should consider building materialized views of your entities in an engine suitable for querying (such as SQL), effectively creating what’s known as the read-side. After all, CQRS and Event Sourcing are used together more often than not. Have a look at Lagom’s implementation, considering it’s built on top of Akka you can hardly find a better reference.
Alternatively, if you do not require powerful querying capabilities, a consumer could listen in on the published entity events and maintain a collection of entities information that you’re interested in. Whenever you wish to send a command to all or subset of those actors, you can instruct the consumer to broadcast the command in question. If you think about it, it’s not much different than the approach above but you might want to save yourself the trouble of adding yet another database engine into the picture if it’s not really needed.
Given that you will likely passivate your actors in order to free up memory, you could use the pre-start phase of the actor to request updates from another actor/register. Similarly, active actors could use timers to do the same.
Depending on the volume of your data, you could use the Distributed Data module.
And the list goes on. As I say, it all depends on your context. Akka is quite powerful and enables you to come with ingenious ways of tackling all sort of problems.
Now to unpack the example situation you’ve presented: upgrade all Australian residents to Premium Membership. Without any knowledge about the domain, I am going to assume that having a full-blown a read-side is optimal. And since I’ve referred to Lagom’s one as a starting point, I will consider the query problem solved (indeed, just like that!) and take a look at the next part of the problem - sending a command to all of the user actors.
Looking at the requirement, my immediate instinct is to ask myself few important questions that will help determine what’s the best way handle the “broadcast” to the actors.
How many users do we have in Australia? I most certainly don’t want to hammer my system to death, so I might want to run these upgrades in a controlled manner (say, in batches). After all, this is not a typical UPDATE … WHERE statement I am running here.
What happens if the system crashes mid-flight, so to speak? I should probably want to maintain some state, allowing me to recover from failure? But then, how do I trigger this operation again?
And so forth …
The point I am trying to make is this, while Event Sourcing is great for modelling complex systems it does force you to think carefully about the consequences of the group operations you intend to run, especially when it’s on a large scale. Otherwise, you risk leaving your system in an undesirable state or, worse, batter it to death.
Hopefully you’ll find my ramblings useful.