Given an Actor system where some persistent actors can have external identifiers that must be unique, how can we enforce this constraint ?
I would prefer a hierarchy of actors where the parent maintains a set of external identifiers to ensure that it is not yet used when creating a child. The issue with that model is that the hierarchy add dependencies between parent and child while our system is almost flat to have independent actors in their own modules. Another issue may be the throughput where the parent will buffer all creation commands to validate them one by one before creating/delegating to a child actor.
The more I think about it, the more I feel that this will be the simpler solution in our system. However the dependencies may be an issue, but there may be some patterns to reduce the coupling between parent and “child” actors.
Another solution in messaging systems seem to let the actor managing his own unique constraint by sending a message via AtLeastOneDelivery to another actor that represents the unique value. (Like that one https://github.com/mattroberts297/akka-saga-pattern-talk-code)
I’m not sure I understand the question, but persistent actors are often used together with Cluster Sharding. The actors are managed by Sharding and adressed by their identifier.
My persistent actors are already identified. But we have some integrations with external system that uses another identifiers.
Let’s say I create a physical person, he has names and is identified via one UUID. At sometime he may want to add an external identifier like his SSN. Of course there cannot be two persons with the same SSN.
What would you do to ensure that the SSN is not already used ?
I was thinking to have one parent actor with a ‘Set[SSN]’ of already registered SSN. That parent will reject commands like ‘SetSsn(UUID, SSN)’ with a known SSN and forward the other to the identified actor.
But it seems that the inverse is also a common practice. Letting the actor receive the command and try to claim the SSN on a dedicated actor with AtLeastOneDelivery to be sure that the claim command will be delivered.
Having Set[SSN] will eventually scale poorly, but your second option is the correct one - managing this in saga. SSN would be an entity and person entities would attempt to claim it and get either grants or rejections back.