About Isolated mutability

Akka Libraries Actors
1

Actor follows Isolated mutability. How do we design usecases which need to work on the collective view?

For example, a Bank Account Actor which stores balance as its State. Thread based application would maintain a shared object say list of Bank Accounts, having details such as Account number, Account holder info, Balance, etc. With data readily available in such a list, we can easily develop usecases such as “display all the accounts having certain balance”, “Change minimum account balance for all accounts which meet the criteria …”, etc.

I could think of following approach to develop such usecases in Actor based application;

  1. Let parent Actor create child actors, one for each bank account. Let parent actor orchestrate by working with the child actors for getting or setting the data and give the final output.

Queries:n

  1. Lot of interaction is needed in above approach as parent actor need to communicate with all the child actors. What is your opinion?
  1. What are the relevant design patterns?
2

Your approach with a parent actor could work as well as with a shared object projected via a mutex as would be done with traditional approaches.

A downside is when you come to scale your application you’d typically start using cluster sharding to place bank account actors on many machines, then this approach won’t work.

At that point you could use the CQRS pattern to build a read side view from published events. E.g. when a new account is created an event is published and another process builds up a view of all the accounts that can be queried efficiently. There are various technologies you can use to publish events / build read side views, which to use would depend on your use case. Let us know if you want to discuss that further.