Is there a generic way (useful formalisms) to think about data synchronization between two systems, especially in the case of slightly asymmetric roles (eg, one system contain master data, another one specialized set of data, overlapping master data), broken down to individual entities. For simplicity, mapped one to one.
So far I can see the situation modeled as two sets with relation between them (say, A and B). Each set correspond to their system. And each element has some attributes like UPDATED, DELETED, UNCHANGED. As a result, there can be 16 different combinations (include MISSING, when another system lacks element present in the other). Given combination, action is almost obvious (or maybe not).
The above is just my ad hoc model. I guess, there are serious books and practitioners out there, which do it better.
As a result I want to have a procedure, which correctly synchronizes two systems' data and requires a minimal set of attributes to store on each side (for example, last modified date, last synchronized date, element ids, etc). Smaller details (like what to do when both systems have updated element) should also be localized and clearly visible from the formalism itself, not just left to ad hoc decisions.
Even though I've read quite a lot on topics related to systems integrations, I've never seen anything of more or less rigorous. And the only other domain, which comes to mind, is version control systems, but those are too specialized. Also, I am not interested in this question on the specific implementation (eg, using queues or some other components) as I want to get to the bottom of the math of this.
I realized that I have not described some assumptions. One of which is that unfortunately there are no streams of events for the systems, especially, the remote one, so the only option is to make queries (lists as well as for getting/upserting individual elements). However, there are "last modified" timestamps and "local" system can record last synchronization times and remote system ids (if that will be needed). Also, queries can be batched, so theoretically it's possible to fetch all entities of one type. For simplicity, it can be assumed that ids and timestamps can fit into memory at the same time. Also both sides are OLTP type, no big data or high velocity of data involved. Data transfers are bidirectional. Even though systems are using transactions, single transaction is confined to a single query, that is, for example, fetching and then updating can't be done in one transaction. Luckily, only "eventual consistency" is required for synchronization scenarios.
Also, I am trying to use same approach possibly for other systems with the same means of access.