Persistence/Sharding Design Question


We have a system implemented as endpoint nodes and shard nodes, each running in their K8S pods. The endpoint nodes don’t have any logic rather than receiving the HTTP request, using the shard proxy to locate the entity in the shard cluster and pass the information through and receive the response. Entities are stateful with both behaviour and state. Entity instances are looked up based on some information available in the incoming security context like the invoking user’s organization Id.

This works well with most entities with single ownership. However, we have a particular entity that’s owned by two organisations (like request for information from a business to a customer). Currently, we are creating two instances of the entity one keyed by business Id and other by customer Id. This means every time a request from either party occur that necessitates a state transition, we have to first locate the entity based on the current security context, issue the transition, find the Id of the other party from the entity instance and initiate a state transition on the second instance owned by the counter party.

Is there a better design pattern instead of redundantly maintaining entity instances for each owner?

Kind regards

Hi @kunnum,

I don’t think this is a good thing to do. If you are duplicating the entity using different keys, they are basically two different entities and therefore they have two separated transaction boundaries.
You can’t guarantee that they will be consistent with each other over time.

If there is a 1:1 relation between then, you are better of using a compounded key (eg: businessId + customerId) and have a single entity that you can reference by the compounded key.

If you get a businessId and you don’t know they customerId (or vice-versa), you will need to maintain a lookup table somewhere. You would then first look up for the compound key and then send the command to the entity.



Thank you.