We decided to store organizations, and their relations to people also in the people service.
We also decided to synchronize organization information from GISMO.
Implications are:
the soap-bridge sends data to nats subjects organization.update or organization.delete
on organization.update an organization is updated (or created when not exists)
on organization.delete an organization is deleted
Problems:
when an organization is deleted, the relations to the person records also. That is a "good" thing as no dangling links are left in the database.
Using a "soft delete" would make it harder for a client to interpret the data, because an extra lookup would be needed to check if the organization that someone is attached to, still is active. Same goes for server side checking: if a organization would be soft deleted, what would that mean for all relations? Ignore those?
As a person record is sent out to the outside world with its organizations embedded, that means that an update to an organization also means an update to a person. So automatically update all related person records, and sent out a nats message to person.updated?
the soap bridge sends messages out in historical order to both subjects person.* and organization.*. But nats subscribers can only consume them separately, meaning one subscriber for person.*, and one for organization.*. So when you want to restore your data, you would have to restore the organizations first, and then person records? Let's not forget that an attribute like organization_id on a person record triggers an insert/update of an organization too (without additional metadata of course). Splitting those messages into two historical lists creates problems. A possible solution would be to use common prefix one could subscribe to.
We decided to store organizations, and their relations to people also in the people service. We also decided to synchronize organization information from GISMO.
Implications are:
organization.updateororganization.deleteorganization.updatean organization is updated (or created when not exists)organization.deletean organization is deletedProblems:
person.updated?person.*andorganization.*. But nats subscribers can only consume them separately, meaning one subscriber forperson.*, and one fororganization.*. So when you want to restore your data, you would have to restore the organizations first, and then person records? Let's not forget that an attribute likeorganization_idon a person record triggers an insert/update of an organization too (without additional metadata of course). Splitting those messages into two historical lists creates problems. A possible solution would be to use common prefix one could subscribe to.