Reputation: 1275
Actors are fantastic abstractions and allow for heavy concurrency with a lot less code. I've been reading about using Actors to represent domain objects such as users, companies, etc and having that object maintain its own state. This is all fine and well to me but my question is:
If my system has thousands of users and hundreds of thousands of companies, is it pragmatic to represent each one of them as a long-lived Actor?
I believe my approach to a problem I'm trying to solve may not scale as well as I think it will. I'm trying to design a system where a user has access to view different company information and within that information is a list of user-generated company data. I'd want to send a broadcast message to all the company Actors, from a connected User Actor, to return all information the user can see within a given date range. I can approach this problem from a database-driven model but I was interested in a more self-aware object model.
Upvotes: 2
Views: 546
Reputation: 377
Actors are pretty light and creating thousands of them is not an issue. I would be concerned when your solution had a potential to grow to millions of users. The memory footprint may not be justified by benefits of this model.
Once the models grows creation of the actors takes more and more time. Based on your description you'd need to have them created upfront in order to use broadcasting.
It is difficult to judge about benefits of actor model in your case without knowing the details. Based on what you've mentioned already the actor model may not be the best fit.
Upvotes: 2